[opensuse-buildservice] obs-service-gpg-offline
I wrote a simple service, which can automatically check PGP signatures of files using gpg-offline .keyring file: https://build.opensuse.org/package/show?package=obs-service-gpg-offline&project=home%3Asbrabec It could be an alternative to %prep checks during the build process using %gpg-offline macro. This is a simple version and does not take any arguments. It checks online for updates, but it does not fail if the signature is not found in the public servers. Only failure of checks against embedded keyring will fail. It would need further discussion, what to return if: - Key server did not respond. - The key is not found upstream. - The key was revoked. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Montag, 7. Januar 2013, 17:22:06 schrieb Stanislav Brabec:
I wrote a simple service, which can automatically check PGP signatures of files using gpg-offline .keyring file: https://build.opensuse.org/package/show?package=obs-service-gpg-offline&project=home%3Asbrabec
It could be an alternative to %prep checks during the build process using %gpg-offline macro.
This is a simple version and does not take any arguments. It checks online for updates, but it does not fail if the signature is not found in the public servers. Only failure of checks against embedded keyring will fail. It would need further discussion, what to return if:
- Key server did not respond. - The key is not found upstream. - The key was revoked.
Hm, what does a key on a gpg server tell us anyway for the trust of it? Everybody can upload it and this person does not have necessarly a connection to the upstream project. IMHO we should collect validated gpg keys, where we know they are from upstream and put them either into some generic collection (for large projects like kernel, KDE, apache ...) We should also support to put the gpg key beside the sources. In this way we see if the key changes on a version update. Doesn't it also make sense to extend the verify_source service for this task instead of adding another one? But to close with something positive, thanks a lot for spending some work here. IMHO the lacking validation of our sources is one of biggest problem trust wise :) thanks! adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Tue, Jan 08, 2013 at 10:11:04AM +0100, Adrian Schröter wrote:
Am Montag, 7. Januar 2013, 17:22:06 schrieb Stanislav Brabec:
I wrote a simple service, which can automatically check PGP signatures of files using gpg-offline .keyring file: https://build.opensuse.org/package/show?package=obs-service-gpg-offline&project=home%3Asbrabec
It could be an alternative to %prep checks during the build process using %gpg-offline macro.
This is a simple version and does not take any arguments. It checks online for updates, but it does not fail if the signature is not found in the public servers. Only failure of checks against embedded keyring will fail. It would need further discussion, what to return if:
- Key server did not respond. - The key is not found upstream. - The key was revoked.
Hm, what does a key on a gpg server tell us anyway for the trust of it? Everybody can upload it and this person does not have necessarly a connection to the upstream project.
Hi Adrian, atm we expect the .keyring will be manually validated in a Factory review phase by review team. Our assumption is that keyrings won't change too often and if so, then some big red button in webui for reviewers will be needed.
IMHO we should collect validated gpg keys, where we know they are from upstream and put them either into some generic collection (for large projects like kernel, KDE, apache ...)
Initially we wanted to have one package collecting all keyrings. This approach complicates the package submission. Of course, that in some cases, the keyring should be packaged in a separate package.
We should also support to put the gpg key beside the sources. In this way we see if the key changes on a version update.
Sorry for my incompetence, but I live under assumption, that BuildService is the tool tracks the file changes, so the best place where to have .keyring file is together with other sources.
Doesn't it also make sense to extend the verify_source service for this task instead of adding another one?
But to close with something positive, thanks a lot for spending some work here. IMHO the lacking validation of our sources is one of biggest problem trust wise :)
To me it seems that the biggest issue in current implementation is how we can ensure the .keyring validity if package can put and submit what he wants to. So what about to create some dedicated (open)SUSE GPG key and put all verified GPG ids into it's web of trust? Then all we need is to verify if package is signed by this key and if so, then it's a trusted keyring. Thanks for a feedback - hope we will be able to finish it soon Regards Michal Vyskocil
Am Dienstag, 8. Januar 2013, 11:18:34 schrieb Michal Vyskocil:
On Tue, Jan 08, 2013 at 10:11:04AM +0100, Adrian Schröter wrote:
Am Montag, 7. Januar 2013, 17:22:06 schrieb Stanislav Brabec:
I wrote a simple service, which can automatically check PGP signatures of files using gpg-offline .keyring file: https://build.opensuse.org/package/show?package=obs-service-gpg-offline&project=home%3Asbrabec
It could be an alternative to %prep checks during the build process using %gpg-offline macro.
This is a simple version and does not take any arguments. It checks online for updates, but it does not fail if the signature is not found in the public servers. Only failure of checks against embedded keyring will fail. It would need further discussion, what to return if:
- Key server did not respond. - The key is not found upstream. - The key was revoked.
Hm, what does a key on a gpg server tell us anyway for the trust of it? Everybody can upload it and this person does not have necessarly a connection to the upstream project.
Hi Adrian,
atm we expect the .keyring will be manually validated in a Factory review phase by review team. Our assumption is that keyrings won't change too often and if so, then some big red button in webui for reviewers will be needed.
IMHO we should collect validated gpg keys, where we know they are from upstream and put them either into some generic collection (for large projects like kernel, KDE, apache ...)
Initially we wanted to have one package collecting all keyrings. This approach complicates the package submission. Of course, that in some cases, the keyring should be packaged in a separate package.
sounds good.
We should also support to put the gpg key beside the sources. In this way we see if the key changes on a version update.
Sorry for my incompetence, but I live under assumption, that BuildService is the tool tracks the file changes, so the best place where to have .keyring file is together with other sources.
Yes, that was also my proposal here. However, in addition to that it makes sense to me to have also a pool somewhere. Esp. for projects which have a larger amount of package sources. It makes it easier that for example all packages from KDE:Distro:Factory project are using the same key. (Dunno if there are really signed tar balls meanwhile in KDE project, just an example)
Doesn't it also make sense to extend the verify_source service for this task instead of adding another one?
But to close with something positive, thanks a lot for spending some work here. IMHO the lacking validation of our sources is one of biggest problem trust wise :)
To me it seems that the biggest issue in current implementation is how we can ensure the .keyring validity if package can put and submit what he wants to.
So what about to create some dedicated (open)SUSE GPG key and put all verified GPG ids into it's web of trust? Then all we need is to verify if package is signed by this key and if so, then it's a trusted keyring.
sounds good. Just one last remark, we will disallow the submission of dot files. So, maybe the file should be name _keyring instead.
Thanks for a feedback - hope we will be able to finish it soon
Regards Michal Vyskocil -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Tue, Jan 08, 2013 at 01:27:24PM +0100, Adrian Schröter wrote:
Am Dienstag, 8. Januar 2013, 11:18:34 schrieb Michal Vyskocil:
On Tue, Jan 08, 2013 at 10:11:04AM +0100, Adrian Schröter wrote:
Am Montag, 7. Januar 2013, 17:22:06 schrieb Stanislav Brabec:
I wrote a simple service, which can automatically check PGP signatures of files using gpg-offline .keyring file: https://build.opensuse.org/package/show?package=obs-service-gpg-offline&project=home%3Asbrabec
It could be an alternative to %prep checks during the build process using %gpg-offline macro.
This is a simple version and does not take any arguments. It checks online for updates, but it does not fail if the signature is not found in the public servers. Only failure of checks against embedded keyring will fail. It would need further discussion, what to return if:
- Key server did not respond. - The key is not found upstream. - The key was revoked.
Hm, what does a key on a gpg server tell us anyway for the trust of it? Everybody can upload it and this person does not have necessarly a connection to the upstream project.
Hi Adrian,
atm we expect the .keyring will be manually validated in a Factory review phase by review team. Our assumption is that keyrings won't change too often and if so, then some big red button in webui for reviewers will be needed.
IMHO we should collect validated gpg keys, where we know they are from upstream and put them either into some generic collection (for large projects like kernel, KDE, apache ...)
Initially we wanted to have one package collecting all keyrings. This approach complicates the package submission. Of course, that in some cases, the keyring should be packaged in a separate package.
sounds good.
We should also support to put the gpg key beside the sources. In this way we see if the key changes on a version update.
Sorry for my incompetence, but I live under assumption, that BuildService is the tool tracks the file changes, so the best place where to have .keyring file is together with other sources.
Yes, that was also my proposal here.
However, in addition to that it makes sense to me to have also a pool somewhere. Esp. for projects which have a larger amount of package sources. It makes it easier that for example all packages from KDE:Distro:Factory project are using the same key.
(Dunno if there are really signed tar balls meanwhile in KDE project, just an example)
OK, now I understood - create pools in cases, where it makes a sense.
Doesn't it also make sense to extend the verify_source service for this task instead of adding another one?
But to close with something positive, thanks a lot for spending some work here. IMHO the lacking validation of our sources is one of biggest problem trust wise :)
To me it seems that the biggest issue in current implementation is how we can ensure the .keyring validity if package can put and submit what he wants to.
So what about to create some dedicated (open)SUSE GPG key and put all verified GPG ids into it's web of trust? Then all we need is to verify if package is signed by this key and if so, then it's a trusted keyring.
sounds good.
Then we need someone will and can do that ;-)
Just one last remark, we will disallow the submission of dot files. So, maybe the file should be name _keyring instead.
Don't worry - the naming scheme is %{NAME}.keyring. Making such files invisible is definitelly a bad idea. But it's great that you plan to abadon dotted files from osc. Regards Michal Vyskocil
Michal Vyskocil wrote:
On Tue, Jan 08, 2013 at 01:27:24PM +0100, Adrian Schröter wrote:
However, in addition to that it makes sense to me to have also a pool somewhere. Esp. for projects which have a larger amount of package sources. It makes it easier that for example all packages from KDE:Distro:Factory project are using the same key.
(Dunno if there are really signed tar balls meanwhile in KDE project, just an example)
OK, now I understood - create pools in cases, where it makes a sense.
It is easy to do for %prep phase validation. Just add keyring package to BuildRequires and use %gpg_offline with -f. I can prepare some support for it. But it makes validation from inside a Build Service a bit more complicated, at the keyring is not part of sources and OBS would fetch the keyring from somewhere. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Tuesday 2013-01-08 16:43, Stanislav Brabec wrote:
OK, now I understood - create pools in cases, where it makes a sense.
It is easy to do for %prep phase validation. Just add keyring package to BuildRequires and use %gpg_offline with -f. I can prepare some support for it.
But it makes validation from inside a Build Service a bit more complicated, at the keyring is not part of sources and OBS would fetch the keyring from somewhere.
The keyring would be part of another package which in turn is in OBS. No problem there, would there be.. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Jan Engelhardt wrote:
On Tuesday 2013-01-08 16:43, Stanislav Brabec wrote:
OK, now I understood - create pools in cases, where it makes a sense.
It is easy to do for %prep phase validation. Just add keyring package to BuildRequires and use %gpg_offline with -f. I can prepare some support for it.
But it makes validation from inside a Build Service a bit more complicated, at the keyring is not part of sources and OBS would fetch the keyring from somewhere.
The keyring would be part of another package which in turn is in OBS. No problem there, would there be..
If I understand correctly, obs service run before the build environment is created. Everything needed for service files has to be part of the build virtual engine image. On the other hand, services have a network access. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Tuesday 2013-01-08 17:36, Stanislav Brabec wrote:
Jan Engelhardt wrote:
On Tuesday 2013-01-08 16:43, Stanislav Brabec wrote:
OK, now I understood - create pools in cases, where it makes a sense.
It is easy to do for %prep phase validation. Just add keyring package to BuildRequires and use %gpg_offline with -f. I can prepare some support for it.
But it makes validation from inside a Build Service a bit more complicated, at the keyring is not part of sources and OBS would fetch the keyring from somewhere.
The keyring would be part of another package which in turn is in OBS. No problem there, would there be..
If I understand correctly, obs service run before the build environment is created. Everything needed for service files has to be part of the build virtual engine image. On the other hand, services have a network access.
I hate services, I don't intend to use them. The island test must succeed, at any time! ;-) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Jan Engelhardt wrote:
I hate services, I don't intend to use them. The island test must succeed, at any time! ;-)
You can run it locally: osc service run gpg-offline -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Dienstag, 8. Januar 2013, 17:36:47 schrieb Stanislav Brabec:
Jan Engelhardt wrote:
On Tuesday 2013-01-08 16:43, Stanislav Brabec wrote:
OK, now I understood - create pools in cases, where it makes a sense.
It is easy to do for %prep phase validation. Just add keyring package to BuildRequires and use %gpg_offline with -f. I can prepare some support for it.
But it makes validation from inside a Build Service a bit more complicated, at the keyring is not part of sources and OBS would fetch the keyring from somewhere.
The keyring would be part of another package which in turn is in OBS. No problem there, would there be..
If I understand correctly, obs service run before the build environment is created. Everything needed for service files has to be part of the build virtual engine image. On the other hand, services have a network access.
It would be similar to the source validator. The trusted keys are installed on developers workstation and also on the service server. If the package on the developers workstation is not in sync with the server (or factory-auto bot) it might be the case that he can commit, but the submit request will be declined (or vice versa). Not nice but not a big problem. We just need to ensure that the factory review bot has always the current valid version with trusted keys. As usual you can skip local services, but you would have extra work since the request gets declined and must be fixed in a second step.
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Michal Vyskocil wrote:
To me it seems that the biggest issue in current implementation is how we can ensure the .keyring validity if package can put and submit what he wants to.
So what about to create some dedicated (open)SUSE GPG key and put all verified GPG ids into it's web of trust? Then all we need is to verify if package is signed by this key and if so, then it's a trusted keyring.
Well, suppose we have an "openSUSE signing key" and all signing keys of packages have to be in the web of trust. Would it be a real security benefit? If somebody writes to openSUSE signing key maintainer: Please sign 2753E77A, I need it for smartmontools. Signing key maintainer would have to ultimately trust the package maintainer. Would the key maintainer sign 2753E77A directly? But the key maintainer has only second-hand information about 2753E77A. Or would the key maintainer sign the openSUSE developer's key and openSUSE developer will sign the upstream signing key? But then we would trust more than we want. Or would we require both? Only trusted developers would be able to ask for adding key to web of trust? Well, even worse. What if author of the-tiny-game-0.1.tar.gz.asc would try to submit httpd-2.4.3.tar.bz2.asc signed by his key. Signature check will pass! -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Tue, Jan 08, 2013 at 04:43:02PM +0100, Stanislav Brabec wrote:
Michal Vyskocil wrote:
To me it seems that the biggest issue in current implementation is how we can ensure the .keyring validity if package can put and submit what he wants to.
So what about to create some dedicated (open)SUSE GPG key and put all verified GPG ids into it's web of trust? Then all we need is to verify if package is signed by this key and if so, then it's a trusted keyring.
Well, suppose we have an "openSUSE signing key" and all signing keys of packages have to be in the web of trust.
Would it be a real security benefit?
If somebody writes to openSUSE signing key maintainer: Please sign 2753E77A, I need it for smartmontools. Signing key maintainer would have to ultimately trust the package maintainer.
Would the key maintainer sign 2753E77A directly? But the key maintainer has only second-hand information about 2753E77A.
Or would the key maintainer sign the openSUSE developer's key and openSUSE developer will sign the upstream signing key? But then we would trust more than we want.
Or would we require both? Only trusted developers would be able to ask for adding key to web of trust?
Well, even worse. What if author of the-tiny-game-0.1.tar.gz.asc would try to submit httpd-2.4.3.tar.bz2.asc signed by his key. Signature check will pass!
Well, noone said that in web of trust model won't check the .keyring changes. But it was just an idea, I would say that a current incarnation is secure and flexible enough. Regards Michal Vyskocil
Michal Vyskocil wrote:
On Tue, Jan 08, 2013 at 04:43:02PM +0100, Stanislav Brabec wrote:
Well, even worse. What if author of the-tiny-game-0.1.tar.gz.asc would try to submit httpd-2.4.3.tar.bz2.asc signed by his key. Signature check will pass!
Well, noone said that in web of trust model won't check the .keyring changes. But it was just an idea, I would say that a current incarnation is secure and flexible enough.
Well, it could make sense. Just a question. What is better: - adding keys in that keyring to web of trust - signing the keyring file during submitting to Factory -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Adrian Schröter wrote:
Am Montag, 7. Januar 2013, 17:22:06 schrieb Stanislav Brabec:
I wrote a simple service, which can automatically check PGP signatures of files using gpg-offline .keyring file: https://build.opensuse.org/package/show?package=obs-service-gpg-offline&project=home%3Asbrabec
It could be an alternative to %prep checks during the build process using %gpg-offline macro.
This is a simple version and does not take any arguments. It checks online for updates, but it does not fail if the signature is not found in the public servers. Only failure of checks against embedded keyring will fail. It would need further discussion, what to return if:
- Key server did not respond. - The key is not found upstream. - The key was revoked.
Hm, what does a key on a gpg server tell us anyway for the trust of it? Everybody can upload it and this person does not have necessarly a connection to the upstream project.
I am aware of it. That is why the obs-service-gpg-offline ony validates signatures where package sources contain trusted .keyring file. Signatures are validated only against these keys, no other keys are accepted. Additionally, the service validates, that the contents of the armored human unreadable section corresponds to the human readable header of the specially formatted .keyring file. Online access can be only used for revocation and expiration prolongation. But I am not sure what to do in such situation. Released package cannot start to fail just because the signing key was revoked. Now it just displays problems, but it returns 0 (OK).
IMHO we should collect validated gpg keys, where we know they are from upstream and put them either into some generic collection (for large projects like kernel, KDE, apache ...)
Well, "we personally know the developer" is the ideal situation. But "we don't know the developer, but releases are signed by this key for 10 years" is not bad as well. Well, my first version of the tool used generic collection of keys, but Ludwig Nussel was against it: http://lists.opensuse.org/opensuse-packaging/2012-09/msg00055.html That is why the actual version uses per-package keyrings.
We should also support to put the gpg key beside the sources. In this way we see if the key changes on a version update.
Yes, I already already did it for ~50 packages in Factory, where packagers already added signatures. These packages now contain "trusted keyring" with key used by upstream to sign the last release. I even found one bad signature. Hopefully it was not an attack - the submission was made directly by the developer and he already fixed the bad signature.
Doesn't it also make sense to extend the verify_source service for this task instead of adding another one?
Yes, it is possible. This is just my first attempt. The packages in Factory now use validation in %prep phase, which is not an optimal solution.
But to close with something positive, thanks a lot for spending some work here. IMHO the lacking validation of our sources is one of biggest problem trust wise :)
You are welcome. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (4)
-
Adrian Schröter
-
Jan Engelhardt
-
Michal Vyskocil
-
Stanislav Brabec