FYI - this is my schedule of work needed to sign packages in Copr:
Hardware: ========= Next visit in PHX is planned on June/July. Next one is January of 2015.
Ideal (and most paranoid) setup would require one physical machine for Signing server and one for copr-backend and one wire between them. With no remote access to signing server.
But we have not HW for this.
What we can have is have signing machine in VM with restrictive SW defined network. If that VM can be only one VM on host, then it would be great.
To set up VM and networking and create ansible manifest, can take up to one week.
Software: ========= I would go the obs-sign way. It would require to get one patch into GPG2. Patch is made by SuSe, but does not live in upstream. TMraz (RH packager) preliminary approved this patch, but have few comments, which would need to be address (name of cmd option, no man page...). Then I will try to get it in upstream, but there is risc of rejecting. But TMraz is willing to accept it as patch into Fedora and RH package. This is backup plan. (1.5 week to work on patch, 1 w for communitation with upstream or tmraz) JStribrny promised to re-package obs-sign. (0.5w) We should enhance documentation of obs-sign and likely write HOWTO for deployment. (0.75w) We need to deploy and configure obs-sign on VM. (0.75w) Mutatis mutandis of Copr (1w). Sum it up (5.5 week)
Total = 6.5 weeks
On Thu, May 22, 2014 at 09:58:47AM +0200, Miroslav Suchý wrote:
FYI - this is my schedule of work needed to sign packages in Copr:
Hardware:
Next visit in PHX is planned on June/July. Next one is January of 2015.
Ideal (and most paranoid) setup would require one physical machine for Signing server and one for copr-backend and one wire between them. With no remote access to signing server.
But we have not HW for this.
What we can have is have signing machine in VM with restrictive SW defined network. If that VM can be only one VM on host, then it would be great.
To set up VM and networking and create ansible manifest, can take up to one week.
Software:
I would go the obs-sign way. It would require to get one patch into GPG2. Patch is made by SuSe, but does not live in upstream. TMraz (RH packager) preliminary approved this patch, but have few comments, which would need to be address (name of cmd option, no man page...). Then I will try to get it in upstream, but there is risc of rejecting. But TMraz is willing to accept it as patch into Fedora and RH package. This is backup plan. (1.5 week to work on patch, 1 w for communitation with upstream or tmraz) JStribrny promised to re-package obs-sign. (0.5w) We should enhance documentation of obs-sign and likely write HOWTO for deployment. (0.75w) We need to deploy and configure obs-sign on VM. (0.75w) Mutatis mutandis of Copr (1w). Sum it up (5.5 week)
Total = 6.5 weeks
Has there been any review of the package signing process by security guys? Since this is presumably different from the standard Fedora package signing process, it might make sense to have someone advise, if not done already.
On 05/22/2014 08:47 PM, Paul W. Frields wrote:
Has there been any review of the package signing process by security guys? Since this is presumably different from the standard Fedora package signing process, it might make sense to have someone advise, if not done already.
Will do.
On Fri, May 23, 2014 at 10:07:40AM +0200, Miroslav Suchý wrote:
On 05/22/2014 08:47 PM, Paul W. Frields wrote:
Has there been any review of the package signing process by security guys? Since this is presumably different from the standard Fedora package signing process, it might make sense to have someone advise, if not done already.
Will do.
Cool, I think there is a security@lists.fp.o for just such a thing.
On Thu, 22 May 2014 09:58:47 +0200 Miroslav Suchý msuchy@redhat.com wrote:
FYI - this is my schedule of work needed to sign packages in Copr:
...snip...
But we have not HW for this.
What we can have is have signing machine in VM with restrictive SW defined network. If that VM can be only one VM on host, then it would be great.
If that was the case, then we would have dedicated hardware for it? :) We should be able to put this vm on a vmhost in the cloud network, but not in the cloud and restrict it pretty heavily.
To set up VM and networking and create ansible manifest, can take up to one week.
Software:
I would go the obs-sign way. It would require to get one patch into GPG2. Patch is made by SuSe, but does not live in upstream. TMraz (RH packager) preliminary approved this patch, but have few comments, which would need to be address (name of cmd option, no man page...). Then I will try to get it in upstream, but there is risc of rejecting. But TMraz is willing to accept it as patch into Fedora and RH package. This is backup plan. (1.5 week to work on patch, 1 w for communitation with upstream or tmraz) JStribrny promised to re-package obs-sign. (0.5w) We should enhance documentation of obs-sign and likely write HOWTO for deployment. (0.75w) We need to deploy and configure obs-sign on VM. (0.75w) Mutatis mutandis of Copr (1w). Sum it up (5.5 week)
Total = 6.5 weeks
Some questions:
Is it intended that signing keys are:
* 1 set for all copr or * a key per user or * a key per copr
When are things intended to be signed? At the end of successfull build? Or when someone requests that? Or when they are added to something like the playground repo?
If signing fails, will that fail the build?
Can obs-signd handle multiple incoming connections? Or can it only sign one thing at a time? Would things block waiting to sign?
kevin
On 05/23/2014 05:45 PM, Kevin Fenzi wrote:
- a key per user
key per user
When are things intended to be signed? At the end of successfull build?
At the end of successful build.
If signing fails, will that fail the build?
Should it? Likely yes. I will think about it.
Can obs-signd handle multiple incoming connections? Or can it only sign one thing at a time? Would things block waiting to sign?
It is single threaded application and process packages one by one. But I do not expect that it become bottleneck as the signing should be really fast (no testing thou yet).
infrastructure@lists.fedoraproject.org