Thanks for considering this.
Apologies for the confusion, my description wasn’t clear/precise enough. Also apologies for the wall of text…
handing over the repo would presumably involve handing over the keys (otherwise, why not just fork?)
I’m not sure why this presumption holds. Can you elaborate?
No the keys should/would not be added to the repo.
Is any proposal possible that does not suffer from the observation “This can be circumvented if someone wants to?”
Actually, I agree with your earlier comment here:
A procedure that significantly reduces the probability of adverse events can be useful even if it does not completely eliminate them, especially if the alternatives are much more costly.
Back to your most recent points raised:
Note the two examples that started this topic, my impression is that your proposal would not protect against either of them
Without presuming the signatory’s desire to provide a signed package that allows self trusted updates is consciously thwarted by the same signatory: Can you elaborate on where/how the proposal breaks down for the examples.
My understanding is the proposal resolves this scenario in the event-stream example*: Maintainer/Signatory A casually hands over a package repository to Signatory/Maintainer B. B makes changes to the package and pushes a new version. All users who installed A’s package silently get B’s changes when they update.
Under this proposal, as long as users installed A’s signed release (which contains A’s public keys for the next N releases), or signed their own instance of it, they will not get B’s changes.
Note I am not saying A would be doing anything terrible. Responsibility is B’s alone. So this proposal still allows even encourages such casual handovers - the proposal allows 1) A to guard his users by making a signed self-trusting-updates-from-A release
, 2) A’s users to guard themselves if A does not choose to make such a self-trusting release.
If this proposal was to become the default distribution for packages, and not optional, guarding against people circumventing the guard-rails is justified as a first order priority. I don’t think we are at that point, but it is worthwhile exploring how the foreseeable issues could be addressed.
Pkg logic could be extended to ensure the
Pkg signing key is:
- Not saved under the project folder.
- Removed from the repository history.
Pkg refuses to create the signed release.
I’m not convinced the effort would be justified until it is observed/demonstrated the risk is real.
Like all security/assurance measures, they can be circumvented - but you’d have to hack the
Pkg code… Ideally the
Pkg signing/packaging logic would only be available when
Pkg itself is installed as a signed packaged, and the installed code verified before a signed package is created. Again I think we are getting ahead of ourselves, but this is do-able.
Again, is this worth the effort until it is a known issue that people are hacking
Pkg to make it save the signing key inside the repository and distribute it?
NOTE: It would still be possible for B to distribute their changes if A does the following non-trivial setup and non-casual handover:
- A set up a persistent VM that is used to sign the package, and stores the signing keys outside the package repository.
- A hands over to B the persistent VM as well as the package repository.
As I said every proposal will be vulnerable to the criticism “But this can be circumvented”.