[opensuse-security] Re: [review-team] Submission with changed .keyring
On Wednesday 13 November 2013 10:14:48 Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Michal Vyskocil <mvyskocil@suse.cz>:
Hi all,
in order to get back to the work, I would like to point your attention to https://build.opensuse.org/request/show/206502
Tomcat got new release manager, which means changed tomcat.keyring. As there is no policy how to do that, I've made my best. So tomcat.keyring does use only new key and it is mentioned in .changes including new key and a linked to svn commit adds the new id to tomcat7/KEYS file.
Is there anything else you'd like to mention?
Michal,
I'd seen that request and I really appreciate the way it's documented. It shows that there has been clear thought and not 'just replacing' the .keyring.
Replacing the .keyring MUST be a sensible topic for the review team (if not: we can as well remove the logic: if injecting a random keyring into the package does not result in the verification of the keyring, it's wasted space).
I fail to see why this pops up now when a .keyring was changed. Did somebody verify how those .keyring files where created in the first place? As long as we don't have an automated way to trust keyring files, we have zero security gained. Others have state that the keyring files shouldn't be part of the package they're supposed to validate. Maybe only a very small set of trusted users would be allowed to change that. We only need a package with openSUSE's blessed keyring and require that for gpg-offline verification during build. Put that package into Base:System or openSUSE:Tools or wherever it's save enough and have the security team be the only maintainers. As a Factory reviewer, you would normally trust SUSE's security team and wave through changes to the keyring package. Net result, one less review task that was spoiled since it's inception anyway. CC'ed the sec guys therefore...
I did not yet have time to actually do the KR validation.. but from a .changes entry, I think it's just right.
As said, I can certainly live with mentioning it. Maybe it's even a good idea. It's just not helping anybody ATM. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
Quoting Sascha Peilicke <speilicke@suse.com>:
Replacing the .keyring MUST be a sensible topic for the review team (if not: we can as well remove the logic: if injecting a random keyring into the package does not result in the verification of the keyring, it's wasted space).
I fail to see why this pops up now when a .keyring was changed. Did somebody verify how those .keyring files where created in the first place? As long as we don't have an automated way to trust keyring files, we have zero security gained.
I sure hope they were verified.. otherwise you can just remove them again and consider it wasted time. We DID originally agree on a process on how to do this task. And we also mentioned that we'd want a big red banned to warn about changes in this file. AUTOMATED way of trusting a keyring is just plain useless... and cannot be done.. EVER! This goes against the whole web-of-trust stuff ('somewhere the trust chain has to start.. this you have to establish manually')
Others have state that the keyring files shouldn't be part of the package they're supposed to validate. Maybe only a very small set of trusted users would be allowed to change that.
That's just Jan.. and is not what was agreed on how we follow it for now. Users trust our packages... it is up to the package to establish the trust to upstream. the .keyring file is there for the maintainer/us to be able to trust 'unknown' contributors
We only need a package with openSUSE's blessed keyring and require that for gpg-offline verification during build. Put that package into Base:System or openSUSE:Tools or wherever it's save enough and have the security team be the only maintainers. As a Factory reviewer, you would normally trust SUSE's security team and wave through changes to the keyring package.
yes, that was also discussed: but rejected due to overhead and complexity (in how to get a signed package into the dist)
I did not yet have time to actually do the KR validation.. but from a .changes entry, I think it's just right.
As said, I can certainly live with mentioning it. Maybe it's even a good idea. It's just not helping anybody ATM.
It helps us, the review team, to make sure that there was thought put into the change. It helps us in establishing 'trust' to the packager submitting it.. Dominique -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Wednesday 13 November 2013 13:39:24 Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Sascha Peilicke <speilicke@suse.com>:
Replacing the .keyring MUST be a sensible topic for the review team (if not: we can as well remove the logic: if injecting a random keyring into the package does not result in the verification of the keyring, it's wasted space).
I fail to see why this pops up now when a .keyring was changed. Did somebody verify how those .keyring files where created in the first place? As long as we don't have an automated way to trust keyring files, we have zero security gained.
I sure hope they were verified.. otherwise you can just remove them again and consider it wasted time. We DID originally agree on a process on how to do this task.
And we also mentioned that we'd want a big red banned to warn about changes in this file.
AUTOMATED way of trusting a keyring is just plain useless... and cannot be done.. EVER! This goes against the whole web-of-trust stuff ('somewhere the trust chain has to start.. this you have to establish manually')
Others have state that the keyring files shouldn't be part of the package they're supposed to validate. Maybe only a very small set of trusted users would be allowed to change that.
That's just Jan.. and is not what was agreed on how we follow it for now. Users trust our packages... it is up to the package to establish the trust to upstream.
the .keyring file is there for the maintainer/us to be able to trust 'unknown' contributors
We only need a package with openSUSE's blessed keyring and require that for gpg-offline verification during build. Put that package into Base:System or openSUSE:Tools or wherever it's save enough and have the security team be the only maintainers. As a Factory reviewer, you would normally trust SUSE's security team and wave through changes to the keyring package.
yes, that was also discussed: but rejected due to overhead and complexity (in how to get a signed package into the dist)
Do you honestly expect external contributors to use the mechanism? For externals, the usual motivation for packaging something is to scratch some itch. I wonder if there are people out there itched by upstream tarball verification issues. If they are, they're most likely working for a consultancy or other company which is concerned about OS-level security. These guys definitely can manage to send a mail to opensuse-security@opensuse.org. As an example, take polkit rules. They're in the hands of the sec team for good reason and are handles exactly as I proposed. So far people where able to manage that. Do you have the ML thread ready where this was discussed?
I did not yet have time to actually do the KR validation.. but from a .changes entry, I think it's just right.
As said, I can certainly live with mentioning it. Maybe it's even a good idea. It's just not helping anybody ATM.
It helps us, the review team, to make sure that there was thought put into the change. It helps us in establishing 'trust' to the packager submitting it..
More or less, yes. Of course it's more obvious that the packager changed the keyring on purpose if he documented it. On the other hand he could have just faked the changes entry too. By mandating this, we just added process without solving the underlying issue. So far, I'm inclined to keep my attitude, as long as the feature didn't get it's extra tuning round in the garage, I'm not gonna spend any review time on it. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
On Wed, Nov 13, 2013 at 02:32:29PM +0100, Sascha Peilicke wrote:
On Wednesday 13 November 2013 13:39:24 Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Sascha Peilicke <speilicke@suse.com>:
Replacing the .keyring MUST be a sensible topic for the review team (if not: we can as well remove the logic: if injecting a random keyring into the package does not result in the verification of the keyring, it's wasted space).
I fail to see why this pops up now when a .keyring was changed. Did somebody verify how those .keyring files where created in the first place? As long as we don't have an automated way to trust keyring files, we have zero security gained.
I sure hope they were verified.. otherwise you can just remove them again and consider it wasted time. We DID originally agree on a process on how to do this task.
And we also mentioned that we'd want a big red banned to warn about changes in this file.
AUTOMATED way of trusting a keyring is just plain useless... and cannot be done.. EVER! This goes against the whole web-of-trust stuff ('somewhere the trust chain has to start.. this you have to establish manually')
Others have state that the keyring files shouldn't be part of the package they're supposed to validate. Maybe only a very small set of trusted users would be allowed to change that.
That's just Jan.. and is not what was agreed on how we follow it for now. Users trust our packages... it is up to the package to establish the trust to upstream.
the .keyring file is there for the maintainer/us to be able to trust 'unknown' contributors
We only need a package with openSUSE's blessed keyring and require that for gpg-offline verification during build. Put that package into Base:System or openSUSE:Tools or wherever it's save enough and have the security team be the only maintainers. As a Factory reviewer, you would normally trust SUSE's security team and wave through changes to the keyring package.
yes, that was also discussed: but rejected due to overhead and complexity (in how to get a signed package into the dist)
Do you honestly expect external contributors to use the mechanism? For externals, the usual motivation for packaging something is to scratch some itch. I wonder if there are people out there itched by upstream tarball verification issues. If they are, they're most likely working for a consultancy or other company which is concerned about OS-level security. These guys definitely can manage to send a mail to opensuse-security@opensuse.org.
As an example, take polkit rules. They're in the hands of the sec team for good reason and are handles exactly as I proposed. So far people where able to manage that.
Do you have the ML thread ready where this was discussed?
I did not yet have time to actually do the KR validation.. but from a .changes entry, I think it's just right.
As said, I can certainly live with mentioning it. Maybe it's even a good idea. It's just not helping anybody ATM.
It helps us, the review team, to make sure that there was thought put into the change. It helps us in establishing 'trust' to the packager submitting it..
More or less, yes. Of course it's more obvious that the packager changed the keyring on purpose if he documented it. On the other hand he could have just faked the changes entry too. By mandating this, we just added process without solving the underlying issue.
So far, I'm inclined to keep my attitude, as long as the feature didn't get it's extra tuning round in the garage, I'm not gonna spend any review time on it.
In general, if the change is documented and does not look fishy, let it through. If it looks fishy, mark for review security-team This whole thing is hard to do right and we should see how this can be improved later. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Wed, Nov 13, 2013 at 11:17:10AM +0100, Sascha Peilicke wrote:
On Wednesday 13 November 2013 10:14:48 Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting Michal Vyskocil <mvyskocil@suse.cz>:
Hi all,
in order to get back to the work, I would like to point your attention to https://build.opensuse.org/request/show/206502
Tomcat got new release manager, which means changed tomcat.keyring. As there is no policy how to do that, I've made my best. So tomcat.keyring does use only new key and it is mentioned in .changes including new key and a linked to svn commit adds the new id to tomcat7/KEYS file.
Is there anything else you'd like to mention?
Michal,
I'd seen that request and I really appreciate the way it's documented. It shows that there has been clear thought and not 'just replacing' the .keyring.
Replacing the .keyring MUST be a sensible topic for the review team (if not: we can as well remove the logic: if injecting a random keyring into the package does not result in the verification of the keyring, it's wasted space).
I fail to see why this pops up now when a .keyring was changed. Did somebody verify how those .keyring files where created in the first place? As long as we don't have an automated way to trust keyring files, we have zero security gained.
We have some security gained. The attack might be some inbetween attack, that a new versions is submitted with a incorrect signature.
Others have state that the keyring files shouldn't be part of the package they're supposed to validate. Maybe only a very small set of trusted users would be allowed to change that.
Where to store them otherwise, do a new database? :/
We only need a package with openSUSE's blessed keyring and require that for gpg-offline verification during build. Put that package into Base:System or openSUSE:Tools or wherever it's save enough and have the security team be the only maintainers. As a Factory reviewer, you would normally trust SUSE's security team and wave through changes to the keyring package.
This might be possible, but it does not really scale out :/
Net result, one less review task that was spoiled since it's inception anyway.
CC'ed the sec guys therefore...
Missed this on the list :/ Ciao, Marcus -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
participants (3)
-
Dominique Leuenberger a.k.a. Dimstar -
Marcus Meissner -
Sascha Peilicke