Hi all,
it's about time to finalize our signing policy to get all our packages properly signed as soon as possible. Note that this is just about signing the package itself. How we will manage our keyring and sign that one using master keys is a different story.
At first please have a look at https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages and let me know if there is anything wrong or unclear. I would like to present this little Howto to the TU so that community packages can be signed as well.
To speed things up I'd like to let dbscripts enforce signed packages. This means that from now on no new packages can be uploaded that don't have a signature. We may give the TU a ew days mroe time as this will be new to them.
If you just agree with all this send a +1.
Greetings,
Pierre
Am 30.10.2011 14:12, schrieb Pierre Schmitz:
To speed things up I'd like to let dbscripts enforce signed packages. This means that from now on no new packages can be uploaded that don't have a signature.
+1
We may give the TU a ew days mroe time as this will be new to them.
-1 - they had more than enough time.
On 30 October 2011 14:22, Allan McRae allan@archlinux.org wrote:
On 30/10/11 23:12, Pierre Schmitz wrote:
If you just agree with all this send a +1.
+1
Sounds good.
-- Guillaume
On Sunday 30 October 2011 14:12:20 Pierre Schmitz wrote:
Hi all,
it's about time to finalize our signing policy to get all our packages properly signed as soon as possible. Note that this is just about signing the package itself. How we will manage our keyring and sign that one using master keys is a different story.
At first please have a look at https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages and let me know if there is anything wrong or unclear. I would like to present this little Howto to the TU so that community packages can be signed as well.
To speed things up I'd like to let dbscripts enforce signed packages. This means that from now on no new packages can be uploaded that don't have a signature. We may give the TU a ew days mroe time as this will be new to them.
If you just agree with all this send a +1.
+1 to enforce signed packages. This has been discussed for months and creating a key takes only a few seconds.
-t
Il 30/10/2011 14:12, Pierre Schmitz ha scritto:
Hi all,
it's about time to finalize our signing policy to get all our packages properly signed as soon as possible. Note that this is just about signing the package itself. How we will manage our keyring and sign that one using master keys is a different story.
At first please have a look at https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages and let me know if there is anything wrong or unclear. I would like to present this little Howto to the TU so that community packages can be signed as well.
To speed things up I'd like to let dbscripts enforce signed packages. This means that from now on no new packages can be uploaded that don't have a signature. We may give the TU a ew days mroe time as this will be new to them.
If you just agree with all this send a +1.
+1
On Sun, Oct 30, 2011 at 2:31 PM, Giovanni Scafora giovanni@archlinux.org wrote:
Il 30/10/2011 14:12, Pierre Schmitz ha scritto:
Hi all,
it's about time to finalize our signing policy to get all our packages properly signed as soon as possible. Note that this is just about signing the package itself. How we will manage our keyring and sign that one using master keys is a different story.
At first please have a look at https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages and let me know if there is anything wrong or unclear. I would like to present this little Howto to the TU so that community packages can be signed as well.
To speed things up I'd like to let dbscripts enforce signed packages. This means that from now on no new packages can be uploaded that don't have a signature. We may give the TU a ew days mroe time as this will be new to them.
If you just agree with all this send a +1.
+1
-- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
+1
Ronald
On Sun, Oct 30, 2011 at 02:12:20PM +0100, Pierre Schmitz wrote:
Hi all,
it's about time to finalize our signing policy to get all our packages properly signed as soon as possible. Note that this is just about signing the package itself. How we will manage our keyring and sign that one using master keys is a different story.
At first please have a look at https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages and let me know if there is anything wrong or unclear. I would like to present this little Howto to the TU so that community packages can be signed as well.
To speed things up I'd like to let dbscripts enforce signed packages. This means that from now on no new packages can be uploaded that don't have a signature. We may give the TU a ew days mroe time as this will be new to them.
If you just agree with all this send a +1.
Greetings,
Pierre
-- Pierre Schmitz, http://pierre-schmitz.com
+1.
On 30.10.2011 14:12, Pierre Schmitz wrote:
If you just agree with all this send a +1.
+1
PS: we should get a voting system
On 30 October 2011 14:14, Thomas Bächler thomas@archlinux.org wrote:
Am 30.10.2011 14:12, schrieb Pierre Schmitz:
To speed things up I'd like to let dbscripts enforce signed packages. This means that from now on no new packages can be uploaded that don't have a signature.
+1
We may give the TU a ew days mroe time as this will be new to them.
-1 - they had more than enough time.
I agree with Thomas, +1 about dbscripts. -1 about more time to the TUs.
Am 30.10.2011 14:12, schrieb Pierre Schmitz:
Hi all,
it's about time to finalize our signing policy to get all our packages properly signed as soon as possible. Note that this is just about signing the package itself. How we will manage our keyring and sign that one using master keys is a different story.
At first please have a look at https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages and let me know if there is anything wrong or unclear. I would like to present this little Howto to the TU so that community packages can be signed as well.
To speed things up I'd like to let dbscripts enforce signed packages. This means that from now on no new packages can be uploaded that don't have a signature. We may give the TU a ew days mroe time as this will be new to them.
If you just agree with all this send a +1.
Greetings,
Pierre
+1
On Sun, 30 Oct 2011 14:12:20 +0100 Pierre Schmitz pierre@archlinux.de wrote:
Hi all,
it's about time to finalize our signing policy to get all our packages properly signed as soon as possible. Note that this is just about signing the package itself. How we will manage our keyring and sign that one using master keys is a different story.
At first please have a look at https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages and let me know if there is anything wrong or unclear. I would like to present this little Howto to the TU so that community packages can be signed as well.
To speed things up I'd like to let dbscripts enforce signed packages. This means that from now on no new packages can be uploaded that don't have a signature. We may give the TU a ew days mroe time as this will be new to them.
If you just agree with all this send a +1.
Greetings,
Pierre
I'm building my packages exclusive on pkgbuild.com and there I can't sign packages. If we do the switch in dbscripts then pkgbuild.com should be ready to generate signed packages. As far as I know it isn't possible yet, am I right?
Otherwise I would say +1, but for now -1.
Daniel
Il 30/10/2011 18:56, Daniel Isenmann ha scritto:
I'm building my packages exclusive on pkgbuild.com and there I can't sign packages. If we do the switch in dbscripts then pkgbuild.com should be ready to generate signed packages. As far as I know it isn't possible yet, am I right?
You can build your packages on pkgbuild.com, then download them locally and sign them with gpg --detach-sign package. After, you have to send .sig files (i686 and x86_64) on pkgbuild, then execute extrapkg or similar command.
On 30.10.2011 18:56, Daniel Isenmann wrote:
I'm building my packages exclusive on pkgbuild.com and there I can't sign packages. If we do the switch in dbscripts then pkgbuild.com should be ready to generate signed packages. As far as I know it isn't possible yet, am I right?
So far the only solution is to download the finished package, sign it locally using gpg --detach-sign <file> and then uploading the signature back to pkgbuild.com so commitpkg will find it.
There has been some discussion [1] about remote signing for GPG, but I think they dropped the idea.
[1]: http://lists.gnupg.org/pipermail/gnupg-users/2011-June/042068.html
On Sun, 30 Oct 2011 19:04:51 +0100 Giovanni Scafora giovanni@archlinux.org wrote:
Il 30/10/2011 18:56, Daniel Isenmann ha scritto:
I'm building my packages exclusive on pkgbuild.com and there I can't sign packages. If we do the switch in dbscripts then pkgbuild.com should be ready to generate signed packages. As far as I know it isn't possible yet, am I right?
You can build your packages on pkgbuild.com, then download them locally and sign them with gpg --detach-sign package. After, you have to send .sig files (i686 and x86_64) on pkgbuild, then execute extrapkg or similar command.
Downloading them locally isn't really a solution. Too low bandwidth and most of the time I don't build the packages from home.
If dbscripts get updated without pkgbuild.com supports signing, then I can't build packages.
On Sun, 30 Oct 2011 14:12:20 +0100 Pierre Schmitz pierre@archlinux.de wrote:
Hi all,
it's about time to finalize our signing policy to get all our packages properly signed as soon as possible. Note that this is just about signing the package itself. How we will manage our keyring and sign that one using master keys is a different story.
At first please have a look at https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages and let me know if there is anything wrong or unclear. I would like to present this little Howto to the TU so that community packages can be signed as well.
To speed things up I'd like to let dbscripts enforce signed packages. This means that from now on no new packages can be uploaded that don't have a signature. We may give the TU a ew days mroe time as this will be new to them.
If you just agree with all this send a +1.
Greetings,
Pierre
sure why not.
Am 30.10.2011 19:13, schrieb Daniel Isenmann:
On Sun, 30 Oct 2011 19:04:51 +0100 Giovanni Scafora giovanni@archlinux.org wrote:
Il 30/10/2011 18:56, Daniel Isenmann ha scritto:
I'm building my packages exclusive on pkgbuild.com and there I can't sign packages. If we do the switch in dbscripts then pkgbuild.com should be ready to generate signed packages. As far as I know it isn't possible yet, am I right?
You can build your packages on pkgbuild.com, then download them locally and sign them with gpg --detach-sign package. After, you have to send .sig files (i686 and x86_64) on pkgbuild, then execute extrapkg or similar command.
You can also use commitpkg (as in extrapkg, testingpkg etc.) to sign the file if you put the package into your build tree.
Downloading them locally isn't really a solution. Too low bandwidth and most of the time I don't build the packages from home.
If dbscripts get updated without pkgbuild.com supports signing, then I can't build packages.
I am sorry, but I have no solution for this atm. And who knows how long it takes until gpg is able to do key forwarding and remote signing. So I don't feel we should wait for that. And honestly: the build server with that much people having root access is quite a problem anyway.
Also if you don't even download (and install) some your own packages, maybe a better solution would be to find someone else to maintain them.
Greetings,
Pierre
On Sun, 30 Oct 2011 19:50:43 +0100 Pierre Schmitz pierre@archlinux.de wrote:
Am 30.10.2011 19:13, schrieb Daniel Isenmann:
On Sun, 30 Oct 2011 19:04:51 +0100 Giovanni Scafora giovanni@archlinux.org wrote:
Il 30/10/2011 18:56, Daniel Isenmann ha scritto:
I'm building my packages exclusive on pkgbuild.com and there I can't sign packages. If we do the switch in dbscripts then pkgbuild.com should be ready to generate signed packages. As far as I know it isn't possible yet, am I right?
You can build your packages on pkgbuild.com, then download them locally and sign them with gpg --detach-sign package. After, you have to send .sig files (i686 and x86_64) on pkgbuild, then execute extrapkg or similar command.
You can also use commitpkg (as in extrapkg, testingpkg etc.) to sign the file if you put the package into your build tree.
Downloading them locally isn't really a solution. Too low bandwidth and most of the time I don't build the packages from home.
If dbscripts get updated without pkgbuild.com supports signing, then I can't build packages.
I am sorry, but I have no solution for this atm. And who knows how long it takes until gpg is able to do key forwarding and remote signing. So I don't feel we should wait for that. And honestly: the build server with that much people having root access is quite a problem anyway.
Also if you don't even download (and install) some your own packages, maybe a better solution would be to find someone else to maintain them. Greetings,
Pierre
As it seems that there is no real solution here, I will try to do it like Florian and Giovanni said it. Downloading the package, sign it locally and upload the signature to pkguild again.
Nevertheless we should find a solution to build signed packages on pkgbuild, otherwise we will loose our buildserver here, because I see this as a workaround and not as a solution.
On Sun, 30 Oct 2011 19:06:21 +0100 Florian Pritz bluewind@xinu.at wrote:
On 30.10.2011 18:56, Daniel Isenmann wrote:
I'm building my packages exclusive on pkgbuild.com and there I can't sign packages. If we do the switch in dbscripts then pkgbuild.com should be ready to generate signed packages. As far as I know it isn't possible yet, am I right?
So far the only solution is to download the finished package, sign it locally using gpg --detach-sign <file> and then uploading the signature back to pkgbuild.com so commitpkg will find it.
There has been some discussion [1] about remote signing for GPG, but I think they dropped the idea.
Kerrick Staley last comment [1] on this thread was that they will go with the hash-signing implementation. But it seems that there is nothing new on this topic.
[1]: http://lists.gnupg.org/pipermail/gnupg-users/2011-June/042078.html
On Sun, Oct 30, 2011 at 9:05 PM, Daniel Isenmann daniel.isenmann@gmx.de wrote:
As it seems that there is no real solution here, I will try to do it like Florian and Giovanni said it. Downloading the package, sign it locally and upload the signature to pkguild again.
Nevertheless we should find a solution to build signed packages on pkgbuild, otherwise we will loose our buildserver here, because I see this as a workaround and not as a solution.
I don't think signing remotely is going to be possible, also I don't see the point of it. We anyway have to download the package in order to test it, so we wouldn't really gain anything.
I use a script to download, sign and upload signature, then I test the package locally before pushing it to the repos.
Just my two cents.
Cheers,
Tom
On Sun, 30 Oct 2011 21:32:25 +0100 Tom Gundersen teg@jklm.no wrote:
On Sun, Oct 30, 2011 at 9:05 PM, Daniel Isenmann daniel.isenmann@gmx.de wrote:
As it seems that there is no real solution here, I will try to do it like Florian and Giovanni said it. Downloading the package, sign it locally and upload the signature to pkguild again.
Nevertheless we should find a solution to build signed packages on pkgbuild, otherwise we will loose our buildserver here, because I see this as a workaround and not as a solution.
I don't think signing remotely is going to be possible, also I don't see the point of it. We anyway have to download the package in order to test it, so we wouldn't really gain anything.
Not all packages have to be tested, e.g. a large rebuild against a new library version which you are sure that nothing is broken in your pakage and only needs new linking against the new library. That's only as an example.
I use a script to download, sign and upload signature, then I test the package locally before pushing it to the repos.
Mind if you can provide the script. Such a helper script would help a lot.
Just my two cents.
Cheers,
Tom
On Sun, Oct 30, 2011 at 9:38 PM, Daniel Isenmann daniel.isenmann@gmx.de wrote:
I don't think signing remotely is going to be possible, also I don't see the point of it. We anyway have to download the package in order to test it, so we wouldn't really gain anything.
Not all packages have to be tested, e.g. a large rebuild against a new library version which you are sure that nothing is broken in your pakage and only needs new linking against the new library. That's only as an example.
But surely you will eventually download and install it? That said, I guess there will be cases where it would be useful to not immediately have to download the package (even if I'm struggling to imagine atm).
I use a script to download, sign and upload signature, then I test the package locally before pushing it to the repos.
Mind if you can provide the script. Such a helper script would help a lot.
Sure, it is based on something given to me by another dev on IRC (forgot who). Hopefully they won't sue me for copyright infringement ;-)
It will leave the packages in /tmp for you to test, so you might want to remember to delete them afterwards.
#!/bin/bash
DIR=`mktemp -d /tmp/signpkg.${1}.XXXXX` pushd ${DIR} scp pkgbuild.com:svn-packages/$1/trunk/*.pkg.tar.xz . for i in *.pkg.tar.xz; do # gpg --detach-sign --use-agent -u $KEY "$i" gpg --detach-sign --use-agent "$i" done scp *.pkg.tar.xz.sig pkgbuild.com:svn-packages/$1/trunk/ popd
On Sun, 30 Oct 2011 21:58:35 +0100 Tom Gundersen teg@jklm.no wrote:
On Sun, Oct 30, 2011 at 9:38 PM, Daniel Isenmann daniel.isenmann@gmx.de wrote:
I don't think signing remotely is going to be possible, also I don't see the point of it. We anyway have to download the package in order to test it, so we wouldn't really gain anything.
Not all packages have to be tested, e.g. a large rebuild against a new library version which you are sure that nothing is broken in your pakage and only needs new linking against the new library. That's only as an example.
But surely you will eventually download and install it? That said, I guess there will be cases where it would be useful to not immediately have to download the package (even if I'm struggling to imagine atm).
Sure. I will do that. But mainly I build the packages not at home and that's my main problem. But I will try the method with your small script, thanks for that.
I use a script to download, sign and upload signature, then I test the package locally before pushing it to the repos.
Mind if you can provide the script. Such a helper script would help a lot.
Sure, it is based on something given to me by another dev on IRC (forgot who). Hopefully they won't sue me for copyright infringement ;-)
It will leave the packages in /tmp for you to test, so you might want to remember to delete them afterwards.
#!/bin/bash
DIR=`mktemp -d /tmp/signpkg.${1}.XXXXX` pushd ${DIR} scp pkgbuild.com:svn-packages/$1/trunk/*.pkg.tar.xz . for i in *.pkg.tar.xz; do # gpg --detach-sign --use-agent -u $KEY "$i" gpg --detach-sign --use-agent "$i" done scp *.pkg.tar.xz.sig pkgbuild.com:svn-packages/$1/trunk/ popd
Thanks for that...
Daniel
[2011-10-30 14:12:20 +0100] Pierre Schmitz:
If you just agree with all this send a +1.
I agree with all this.
On 30 October 2011 22:47, Daniel Isenmann daniel.isenmann@gmx.de wrote:
On Sun, 30 Oct 2011 21:58:35 +0100 Tom Gundersen teg@jklm.no wrote:
On Sun, Oct 30, 2011 at 9:38 PM, Daniel Isenmann daniel.isenmann@gmx.de wrote:
I don't think signing remotely is going to be possible, also I don't see the point of it. We anyway have to download the package in order to test it, so we wouldn't really gain anything.
Not all packages have to be tested, e.g. a large rebuild against a new library version which you are sure that nothing is broken in your pakage and only needs new linking against the new library. That's only as an example.
But surely you will eventually download and install it? That said, I guess there will be cases where it would be useful to not immediately have to download the package (even if I'm struggling to imagine atm).
Sure. I will do that. But mainly I build the packages not at home and that's my main problem. But I will try the method with your small script, thanks for that.
I use a script to download, sign and upload signature, then I test the package locally before pushing it to the repos.
Mind if you can provide the script. Such a helper script would help a lot.
Sure, it is based on something given to me by another dev on IRC (forgot who). Hopefully they won't sue me for copyright infringement ;-)
It will leave the packages in /tmp for you to test, so you might want to remember to delete them afterwards.
#!/bin/bash
DIR=`mktemp -d /tmp/signpkg.${1}.XXXXX` pushd ${DIR} scp pkgbuild.com:svn-packages/$1/trunk/*.pkg.tar.xz . for i in *.pkg.tar.xz; do # gpg --detach-sign --use-agent -u $KEY "$i" gpg --detach-sign --use-agent "$i" done scp *.pkg.tar.xz.sig pkgbuild.com:svn-packages/$1/trunk/ popd
Thanks for that...
Daniel
Just in case it can help, I also made a script [0] that updates the svn tree from alderaan to a local tree and rsync the remote packages to a local folder.
I then just need to install, test and if OK I can "extrapkg 'blahblahblah'" from my local machine.
It also works with community packages.
(Don't forget the configuration file [1] if you want to test)
[0] https://raw.github.com/galaux/scripts/master/duppkgbuild/duppkgbuild [1] https://raw.github.com/galaux/scripts/master/duppkgbuild/duppkgbuild.conf
-- Guillaume
On 31/10/11 06:09, Daniel Isenmann wrote:
On Sun, 30 Oct 2011 19:06:21 +0100 Florian Pritzbluewind@xinu.at wrote:
On 30.10.2011 18:56, Daniel Isenmann wrote:
I'm building my packages exclusive on pkgbuild.com and there I can't sign packages. If we do the switch in dbscripts then pkgbuild.com should be ready to generate signed packages. As far as I know it isn't possible yet, am I right?
So far the only solution is to download the finished package, sign it locally using gpg --detach-sign<file> and then uploading the signature back to pkgbuild.com so commitpkg will find it.
There has been some discussion [1] about remote signing for GPG, but I think they dropped the idea.
Kerrick Staley last comment [1] on this thread was that they will go with the hash-signing implementation. But it seems that there is nothing new on this topic.
I'd be much more interested in a patch that actually lets you do remote signing than a discussion that went nowhere...
http://lists.gnupg.org/pipermail/gnupg-devel/2011-July/026170.html
But then again, that patch went nowhere in the end too as far as I can tell.
Allan
On Sun, Oct 30, 2011 at 9:12 AM, Pierre Schmitz pierre@archlinux.de wrote:
Hi all,
it's about time to finalize our signing policy to get all our packages properly signed as soon as possible. Note that this is just about signing the package itself. How we will manage our keyring and sign that one using master keys is a different story.
At first please have a look at https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages and let me know if there is anything wrong or unclear. I would like to present this little Howto to the TU so that community packages can be signed as well.
To speed things up I'd like to let dbscripts enforce signed packages. This means that from now on no new packages can be uploaded that don't have a signature. We may give the TU a ew days mroe time as this will be new to them.
If you just agree with all this send a +1.
+1
Eric
Greetings,
Pierre
-- Pierre Schmitz, http://pierre-schmitz.com
On 31 October 2011 01:56, Daniel Isenmann daniel.isenmann@gmx.de wrote:
I'm building my packages exclusive on pkgbuild.com and there I can't sign packages. If we do the switch in dbscripts then pkgbuild.com should be ready to generate signed packages. As far as I know it isn't possible yet, am I right?
Otherwise I would say +1, but for now -1.
Ditto.
I normally only download and test packages that I use and/or are important/popular, other updates are merely minor version bumps, and sometimes I am bandwidth-constrained to download anything more than a few megs.
But I hope I'm right that most of my packages are lean, in which case downloading the packages and uploading only the sigs then won't be much of a problem. And anyway, there was a time when there was no pkgbuild.com and I had to build packages locally and on slow networks, so I think I can manage.
In general, +1.
-- GPG/PGP ID: 8AADBB10
Le 30 octobre 2011 14:12:20 Pierre Schmitz a écrit :
Hi all,
it's about time to finalize our signing policy to get all our packages properly signed as soon as possible. Note that this is just about signing the package itself. How we will manage our keyring and sign that one using master keys is a different story.
At first please have a look at https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages and let me know if there is anything wrong or unclear. I would like to present this little Howto to the TU so that community packages can be signed as well.
To speed things up I'd like to let dbscripts enforce signed packages. This means that from now on no new packages can be uploaded that don't have a signature. We may give the TU a ew days mroe time as this will be new to them.
If you just agree with all this send a +1.
Greetings,
Pierre
+1
Some TUs never used their real name here, so it will be a good oportunity to discover who they are really :P
Stéphane
On 31 October 2011 02:06, Florian Pritz bluewind@xinu.at wrote:
So far the only solution is to download the finished package, sign it locally using gpg --detach-sign <file> and then uploading the signature back to pkgbuild.com so commitpkg will find it.
Did something change WRT this workflow now? I'm getting signature-incorrect from commitpkg. I did sign like this 2 times before (opencv and cinelerra-cv), so it did work recently. gpg --verify outputs:
gpg: Can't check signature: public key not found
But this is normal, and the public key was not there for the previous 2 times. Or was gpg --verify not there in commitpkg before? Do I now need to import my public key on alderaan?
-- GPG/PGP ID: C0711BF1
On Fri, Nov 11, 2011 at 5:31 PM, Ray Rashif schiv@archlinux.org wrote:
On 31 October 2011 02:06, Florian Pritz bluewind@xinu.at wrote:
So far the only solution is to download the finished package, sign it locally using gpg --detach-sign <file> and then uploading the signature back to pkgbuild.com so commitpkg will find it.
Did something change WRT this workflow now? I'm getting signature-incorrect from commitpkg. I did sign like this 2 times before (opencv and cinelerra-cv), so it did work recently. gpg --verify outputs:
gpg: Can't check signature: public key not found
But this is normal, and the public key was not there for the previous 2 times. Or was gpg --verify not there in commitpkg before? Do I now need to import my public key on alderaan?
Is your key in your keychain on alderaan? Probably not from what this looks like. Easy to check- `gpg --list-keys 0xfoobar`.
-Dan
On 12 November 2011 07:35, Dan McGee dpmcgee@gmail.com wrote:
On Fri, Nov 11, 2011 at 5:31 PM, Ray Rashif schiv@archlinux.org wrote:
On 31 October 2011 02:06, Florian Pritz bluewind@xinu.at wrote:
So far the only solution is to download the finished package, sign it locally using gpg --detach-sign <file> and then uploading the signature back to pkgbuild.com so commitpkg will find it.
Did something change WRT this workflow now? I'm getting signature-incorrect from commitpkg. I did sign like this 2 times before (opencv and cinelerra-cv), so it did work recently. gpg --verify outputs:
gpg: Can't check signature: public key not found
But this is normal, and the public key was not there for the previous 2 times. Or was gpg --verify not there in commitpkg before? Do I now need to import my public key on alderaan?
Is your key in your keychain on alderaan? Probably not from what this looks like. Easy to check- `gpg --list-keys 0xfoobar`.
-Dan
Nope. That was what I was asking - whether I need to add it. The last 2 times that I pushed signed packages from alderaan I didn't do anything gpg-related remotely.
Anyway, imported the key now so all is good again.
-- GPG/PGP ID: C0711BF1
On 11/12/2011 01:43 AM, Ray Rashif wrote:
On 12 November 2011 07:35, Dan McGee dpmcgee@gmail.com wrote:
On Fri, Nov 11, 2011 at 5:31 PM, Ray Rashif schiv@archlinux.org wrote:
On 31 October 2011 02:06, Florian Pritz bluewind@xinu.at wrote:
So far the only solution is to download the finished package, sign it locally using gpg --detach-sign <file> and then uploading the signature back to pkgbuild.com so commitpkg will find it.
Did something change WRT this workflow now? I'm getting signature-incorrect from commitpkg. I did sign like this 2 times before (opencv and cinelerra-cv), so it did work recently. gpg --verify outputs:
gpg: Can't check signature: public key not found
But this is normal, and the public key was not there for the previous 2 times. Or was gpg --verify not there in commitpkg before? Do I now need to import my public key on alderaan?
Is your key in your keychain on alderaan? Probably not from what this looks like. Easy to check- `gpg --list-keys 0xfoobar`.
-Dan
Nope. That was what I was asking - whether I need to add it. The last 2 times that I pushed signed packages from alderaan I didn't do anything gpg-related remotely.
Anyway, imported the key now so all is good again.
-- GPG/PGP ID: C0711BF1
don't import any key on alderaan.
is a devtools requirement that a signature must exist to enforce packagers to sign their packages. Imo we should try to do that optionally on alderaan or even better, use svn commit and commitpkg only locally after copying the packages.
On Fri, Nov 11, 2011 at 5:56 PM, Ionut Biru ibiru@archlinux.org wrote:
On 11/12/2011 01:43 AM, Ray Rashif wrote:
On 12 November 2011 07:35, Dan McGee dpmcgee@gmail.com wrote:
On Fri, Nov 11, 2011 at 5:31 PM, Ray Rashif schiv@archlinux.org wrote:
On 31 October 2011 02:06, Florian Pritz bluewind@xinu.at wrote:
So far the only solution is to download the finished package, sign it locally using gpg --detach-sign <file> and then uploading the signature back to pkgbuild.com so commitpkg will find it.
Did something change WRT this workflow now? I'm getting signature-incorrect from commitpkg. I did sign like this 2 times before (opencv and cinelerra-cv), so it did work recently. gpg --verify outputs:
gpg: Can't check signature: public key not found
But this is normal, and the public key was not there for the previous 2 times. Or was gpg --verify not there in commitpkg before? Do I now need to import my public key on alderaan?
Is your key in your keychain on alderaan? Probably not from what this looks like. Easy to check- `gpg --list-keys 0xfoobar`.
-Dan
Nope. That was what I was asking - whether I need to add it. The last 2 times that I pushed signed packages from alderaan I didn't do anything gpg-related remotely.
Anyway, imported the key now so all is good again.
-- GPG/PGP ID: C0711BF1
don't import any key on alderaan.
Hmm?
He is trying to *verify*, meaning he needs his *public* key. This has nothing to do with signing or private keys. It make a heck of a lot more sense bandwidth-wise for him to upload the signature file to alderaan than upload both the package and signature from his local machine, so why should he not be able to do that? The `gpg --verify` call is there to make sure developers don't accidentally upload mismatched packages and corresponding signature files, which could easily happen when doing test builds and --nosign, etc.
-Dan
On 11/12/2011 01:59 AM, Dan McGee wrote:
On Fri, Nov 11, 2011 at 5:56 PM, Ionut Biru ibiru@archlinux.org wrote:
On 11/12/2011 01:43 AM, Ray Rashif wrote:
On 12 November 2011 07:35, Dan McGee dpmcgee@gmail.com wrote:
On Fri, Nov 11, 2011 at 5:31 PM, Ray Rashif schiv@archlinux.org wrote:
On 31 October 2011 02:06, Florian Pritz bluewind@xinu.at wrote:
So far the only solution is to download the finished package, sign it locally using gpg --detach-sign <file> and then uploading the signature back to pkgbuild.com so commitpkg will find it.
Did something change WRT this workflow now? I'm getting signature-incorrect from commitpkg. I did sign like this 2 times before (opencv and cinelerra-cv), so it did work recently. gpg --verify outputs:
gpg: Can't check signature: public key not found
But this is normal, and the public key was not there for the previous 2 times. Or was gpg --verify not there in commitpkg before? Do I now need to import my public key on alderaan?
Is your key in your keychain on alderaan? Probably not from what this looks like. Easy to check- `gpg --list-keys 0xfoobar`.
-Dan
Nope. That was what I was asking - whether I need to add it. The last 2 times that I pushed signed packages from alderaan I didn't do anything gpg-related remotely.
Anyway, imported the key now so all is good again.
-- GPG/PGP ID: C0711BF1
don't import any key on alderaan.
Hmm?
He is trying to *verify*, meaning he needs his *public* key. This has nothing to do with signing or private keys. It make a heck of a lot more sense bandwidth-wise for him to upload the signature file to alderaan than upload both the package and signature from his local machine, so why should he not be able to do that? The `gpg --verify` call is there to make sure developers don't accidentally upload mismatched packages and corresponding signature files, which could easily happen when doing test builds and --nosign, etc.
-Dan
well, i understood that he signed the package on alderaan...
On 12 November 2011 08:04, Ionut Biru ibiru@archlinux.org wrote:
On 11/12/2011 01:59 AM, Dan McGee wrote:
On Fri, Nov 11, 2011 at 5:56 PM, Ionut Biru ibiru@archlinux.org wrote:
On 11/12/2011 01:43 AM, Ray Rashif wrote:
On 12 November 2011 07:35, Dan McGee dpmcgee@gmail.com wrote:
On Fri, Nov 11, 2011 at 5:31 PM, Ray Rashif schiv@archlinux.org wrote:
On 31 October 2011 02:06, Florian Pritz bluewind@xinu.at wrote: > So far the only solution is to download the finished package, sign it > locally using gpg --detach-sign <file> and then uploading the signature > back to pkgbuild.com so commitpkg will find it.
Did something change WRT this workflow now? I'm getting signature-incorrect from commitpkg. I did sign like this 2 times before (opencv and cinelerra-cv), so it did work recently. gpg --verify outputs:
gpg: Can't check signature: public key not found
But this is normal, and the public key was not there for the previous 2 times. Or was gpg --verify not there in commitpkg before? Do I now need to import my public key on alderaan?
Is your key in your keychain on alderaan? Probably not from what this looks like. Easy to check- `gpg --list-keys 0xfoobar`.
-Dan
Nope. That was what I was asking - whether I need to add it. The last 2 times that I pushed signed packages from alderaan I didn't do anything gpg-related remotely.
Anyway, imported the key now so all is good again.
-- GPG/PGP ID: C0711BF1
don't import any key on alderaan.
Hmm?
He is trying to *verify*, meaning he needs his *public* key. This has nothing to do with signing or private keys. It make a heck of a lot more sense bandwidth-wise for him to upload the signature file to alderaan than upload both the package and signature from his local machine, so why should he not be able to do that? The `gpg --verify` call is there to make sure developers don't accidentally upload mismatched packages and corresponding signature files, which could easily happen when doing test builds and --nosign, etc.
-Dan
well, i understood that he signed the package on alderaan...
Then you misunderstood. My reply to the topic meant I was referring to the only workaround to "sign packages on alderaan", which is to build, download packages, sign locally, upload signatures, and then push wholesale.
I followed that process on 2 previous occasions and there was no complaint even when there was no public key on the remote machine, but this time commitpkg complained about the signatures. So I only wanted to know whether I did anything wrong.
Anyway, it's now evident that the verification was not there before. Importing a public key poses no risk (done with --recv-keys), so there is also no need to change anything in commitpkg.
-- GPG/PGP ID: C0711BF1
arch-dev-public@lists.archlinux.org