Conversation
@Foxboron
@fabiscafe @Mehrad @dvzrv
I always assumed it was to avoid having to maintain a centralised signing infrastructure? With all the care that needs to be taken to avoid compromise of a high-value target that a distribution signing key would be? I don't think this is a totally crazy tradeoff to make, and TBH I consider the occasional manual update of the keyring package a minor annoyance at most...
@fabiscafe @Mehrad @dvzrv
I always assumed it was to avoid having to maintain a centralised signing infrastructure? With all the care that needs to be taken to avoid compromise of a high-value target that a distribution signing key would be? I don't think this is a totally crazy tradeoff to make, and TBH I consider the occasional manual update of the keyring package a minor annoyance at most...
2
0
0
@Foxboron
@dvzrv @Mehrad @fabiscafe
Well, from a user PoV, an undiscovered compromise of a developer signing key would potentially result in a malicious package ending up on my system whether the dev key is directly trusted by my local system, or whether it's transitively trusted by the automatic resigning system. And transparency logging could be implemented without resigning the packages (I think?).
Which means that the main benefit would be that a compromised dev key could be revoked quicker in the centralised setup. Offset by the fact that an already-distributed malicious package can't be revoked individually without rotating the full distro signing key.
I don't actually consider myself immensely qualified to say anything about the magnitude of the relative risks involved here; I think I would probably agree with you that the resigning model is preferable, on balance. My point was more that I can see why someone would make the opposite call when factoring in the cost and risk of running the centralised infrastructure, especially 10 years ago :)
@dvzrv @Mehrad @fabiscafe
Well, from a user PoV, an undiscovered compromise of a developer signing key would potentially result in a malicious package ending up on my system whether the dev key is directly trusted by my local system, or whether it's transitively trusted by the automatic resigning system. And transparency logging could be implemented without resigning the packages (I think?).
Which means that the main benefit would be that a compromised dev key could be revoked quicker in the centralised setup. Offset by the fact that an already-distributed malicious package can't be revoked individually without rotating the full distro signing key.
I don't actually consider myself immensely qualified to say anything about the magnitude of the relative risks involved here; I think I would probably agree with you that the resigning model is preferable, on balance. My point was more that I can see why someone would make the opposite call when factoring in the cost and risk of running the centralised infrastructure, especially 10 years ago :)
1
0
0
@Foxboron
@dvzrv @Mehrad @fabiscafe
Hmm, so IIUC, the function of a transparency log in a package signing context is basically that you can say "if I ever encounter a package with a valid signature but no entry in the transparency log, something fishy is going on". Right?
In which case that seems orthogonal to which keys do the signing? If you're building a log of the signatures of dev keys it would supposedly happen at the point where the package is uploaded to the mirrors, and so the same kind of verification of the log could be done?
It would be problem for any developer who wanted to have a separate private repo signed with the same key, I guess, but that seems like a "don't do that, then" kind of issue?
Anyway, I guess this is a bit of a hypothetical discussion anyway as it's not terribly likely that anyone is going to build such a log. And if you do end up with some kind of transparency log you'd probably want it to tie all the way back to the sources, not just attesting binary build blobs? Which also implies centralised build servers...
@dvzrv @Mehrad @fabiscafe
Hmm, so IIUC, the function of a transparency log in a package signing context is basically that you can say "if I ever encounter a package with a valid signature but no entry in the transparency log, something fishy is going on". Right?
In which case that seems orthogonal to which keys do the signing? If you're building a log of the signatures of dev keys it would supposedly happen at the point where the package is uploaded to the mirrors, and so the same kind of verification of the log could be done?
It would be problem for any developer who wanted to have a separate private repo signed with the same key, I guess, but that seems like a "don't do that, then" kind of issue?
Anyway, I guess this is a bit of a hypothetical discussion anyway as it's not terribly likely that anyone is going to build such a log. And if you do end up with some kind of transparency log you'd probably want it to tie all the way back to the sources, not just attesting binary build blobs? Which also implies centralised build servers...
0
0
0