develop strategy for close-sourcing sensitive server components #245

New issue

Closed

opened 2025-10-14 15:53:48 -06:00 by navan · 0 comments

navan commented

2025-10-14 15:53:48 -06:00

Owner

Originally created by @tayloraswift on 3/25/2024

for background, we know that somebody spent a lot of effort trying to take the Swiftinit site offline in Q4 2023, and that these attempts have continued sporadically into Q1 2024. the nature of the attacks and the endpoints they hit suggest (to me at least) that the attacker had read the source code for the server and had at least some knowledge of how the documentation service works and how to disrupt it.

we should not rely on security through obscurity, and as a project ostensibly motivated by the public interest, it would be ideal if we could continue practicing open security. however, this has proved unworkable in practice, as it slows us down considerably and prevents us from prototyping and shipping new features without extensive security auditing, as we must assume that hostile entities are watching the project and can notice new, insufficiently-secured endpoints.

close-sourcing enough of the project to keep the production site safe while still keeping enough of the project open source to provide a meaningful public benefit will require some amount of planning. we should investigate:

spinning off peripheral components of the repo into standalone libraries in their own right
refactoring the server into a stripped-down version suitable for local testing, and a secret version to use in production. this means dividing the SwiftinitServer target.

*Originally created by @tayloraswift on 3/25/2024* for background, we know that [somebody spent a lot of effort](https://forums.swift.org/t/how-to-help-fortify-swift-nio-against-dos/67990) trying to take the Swiftinit site offline in Q4 2023, and that these attempts have continued sporadically into Q1 2024. the nature of the attacks and the endpoints they hit suggest (to me at least) that the attacker had read the source code for the server and had at least some knowledge of how the documentation service works and how to disrupt it. we should not rely on [security through obscurity](https://en.wikipedia.org/wiki/Security_through_obscurity), and as a project ostensibly motivated by the public interest, it would be ideal if we could continue practicing [open security](https://en.wikipedia.org/wiki/Open_security). however, this has proved unworkable in practice, as it slows us down considerably and prevents us from prototyping and shipping new features without extensive security auditing, as we must assume that hostile entities are watching the project and can notice new, insufficiently-secured endpoints. close-sourcing enough of the project to keep the production site safe while still keeping enough of the project open source to provide a meaningful public benefit will require some amount of planning. we should investigate: - spinning off peripheral components of the repo into standalone libraries in their own right - refactoring the server into a stripped-down version suitable for local testing, and a secret version to use in production. this means dividing the `SwiftinitServer` target.