Hi. It looks like the gpg signatures of the RC2 and RC3 tarballs are bogus... I've tested the .bz2 and .tar.gz files downloaded from the us1 and us4 mirrors. To confirm that it's not a local problem, I've tested the signature of the Samba_CA.crt file (http://us4.samba.org/samba/ftp/) and it's ok. Can someone else please confirm it? Thanks. - Ademar $ gpg --verify Samba_CA.crt.asc Samba_CA.crt gpg: Signature made Tue 06 May 2003 12:55:54 PM BRT using DSA key ID 2F87AF6F gpg: Good signature from "Samba Distribution Verification Key <samba-bugs@samba.org>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 3275 F01D 6565 3A81 AE7B 320C D779 0A5F 2F87 AF6F $ gpg --verify samba-3.0.0rc3.tar.asc samba-3.0.0rc3.tar.bz2 gpg: Signature made Mon Sep 8 15:17:37 2003 BRT using DSA key ID 2F87AF6F gpg: BAD signature from "Samba Distribution Verification Key <samba-bugs@samba.org>" $ gpg --verify samba-3.0.0rc3.tar.asc samba-3.0.0rc3.tar.gz gpg: Signature made Mon Sep 8 15:17:37 2003 BRT using DSA key ID 2F87AF6F gpg: BAD signature from "Samba Distribution Verification Key <samba-bugs@samba.org>" $ gpg --verify samba-3.0.0rc2.tar.asc samba-3.0.0rc2.tar.bz2 gpg: Signature made Fri Aug 29 01:14:15 2003 BRT using DSA key ID 2F87AF6F gpg: BAD signature from "Samba Distribution Verification Key <samba-bugs@samba.org>" -- Ademar de Souza Reis Jr. <ademar@conectiva.com.br> ^[:wq! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/20030909/1b0e2b62/attachment.bin
On Tue, Sep 09, 2003 at 07:04:51PM -0300, Ademar de Souza Reis Jr. wrote:> Hi. > > It looks like the gpg signatures of the RC2 and RC3 tarballs > are bogus... I've tested the .bz2 and .tar.gz files downloaded from the > us1 and us4 mirrors.Decompress the tarball first. The sig is on the original tarball, so that transparent browser decompression, and the two different compressions do not mess it up. Andrew Bartlett