Bug#315538: dput doesn't refuse to operate on doubly-signed .changes
# Bcc: control reassign 315538 lintian thanks On 06/07/21 14:43 +0200, Jeroen van Wolffelaar said ... > On Sun, Jul 16, 2006 at 04:09:25PM +0200, Thijs Kinkhorst wrote: > > Jeroen van Wolffelaar wrote: > > > > > dput doesn't refuse to operate on doubly-signed .changes. But katie > > > will choke on those, and is not able to extract the Uploader, so the > > > uploader won't get any feedback. > > [...] > > > It's not large, but when it happens, there is no feedback on what > > > happened, as the upload queue processor does *not* fail on it but > > > reports success back, and then you get silence. > > > > What I'm missing here is why not fix the tools that don't give the right > > feedback rather than trying to patch every possible method of uploading > > new packages? I'd attack the problem at the source. > > This would mean that the queue processer would need to gain a fuzzy > parser: need to cope with random data prepended, and still find > out/guess what's the problem. > > It's much easier for dput (and co) to gain some check whether the signed > content actually looks like a .changes file, that is, consists of "Key: > value" pairs and has at least the mandatory fields (and maybe also check > whether the email address listed looks like a valid address and not > something @local or so). This would also catch other potential mistakes. > The queue processing software uses a standard 'mail header' parser, > which breaks parsing on the first newline, which happens to be before > the intended content. This certainly looks like what lintian [wsc]ould be doing. I tried a bad changes file (double signed) and this is what lintian says right now. $ lintian -I axel_1.1-3_i386.changes Use of uninitialized value in string ne at /usr/bin/lintian line 647. E: axel_1.1-3_i386.changes: no-description-in-changes-file W: axel_1.1-3_i386.changes: no-urgency-in-changes-file While this is not really an identification of the problem (I poked at lintian and noticed that it tries to look for key:value pairs after the signature), I suppose it is a good check to indicate that something is seriously wrong. Essentially, I am suggesting running dput with lintian checking as a solid workaround for the feature requested. I will leave it to the lintian maintainers to comment on the double-sign detection. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
Bug#315538: dput doesn't refuse to operate on doubly-signed .changes
On Fri, 2006-07-21 at 14:43 +0200, Jeroen van Wolffelaar wrote: > This would mean that the queue processer would need to gain a fuzzy > parser: need to cope with random data prepended, and still find > out/guess what's the problem. > > It's much easier for dput (and co) to gain some check whether the signed Well, you'd need to code a check into two different languages already (for dupload and dput) and would not catch anyone just uploading with ftp or any possible new tool that would come by. > content actually looks like a .changes file, that is, consists of "Key: > value" pairs and has at least the mandatory fields (and maybe also check > whether the email address listed looks like a valid address and not > something @local or so). This would also catch other potential mistakes. > The queue processing software uses a standard 'mail header' parser, > which breaks parsing on the first newline, which happens to be before > the intended content. One very simple 'grep' on the file would turn out a usable point of contact. Another quite simple solution is as long as the changes file starts with '-BEGIN PGP SIGNED MESSAGE-' to remove the signature (instead of doing it once). In both cases you've solved the problem for every case and in one place, and don't need to write code for the different tools people use or don't use. Thijs signature.asc Description: This is a digitally signed message part
Bug#315538: dput doesn't refuse to operate on doubly-signed .changes
retitle 315538 dput: add syntax check for .changes thanks Hi Jeroen, indeed, dput could easily do the check for a valid changes file format (the title has been a red herring here), and I'm willing to include such a check. Jeroen van Wolffelaar wrote: > This would mean that the queue processer would need to gain a fuzzy > parser: need to cope with random data prepended, and still find > out/guess what's the problem. No, the queue processor could simply send it's error output to an address in the signing key's UID, AFAICT jennifer 1259 et sqq. only processes changes after checking for a signature from a keyring key. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315538: dput doesn't refuse to operate on doubly-signed .changes
On Sun, Jul 16, 2006 at 04:09:25PM +0200, Thijs Kinkhorst wrote: > Jeroen van Wolffelaar wrote: > > > dput doesn't refuse to operate on doubly-signed .changes. But katie > > will choke on those, and is not able to extract the Uploader, so the > > uploader won't get any feedback. > [...] > > It's not large, but when it happens, there is no feedback on what > > happened, as the upload queue processor does *not* fail on it but > > reports success back, and then you get silence. > > What I'm missing here is why not fix the tools that don't give the right > feedback rather than trying to patch every possible method of uploading > new packages? I'd attack the problem at the source. This would mean that the queue processer would need to gain a fuzzy parser: need to cope with random data prepended, and still find out/guess what's the problem. It's much easier for dput (and co) to gain some check whether the signed content actually looks like a .changes file, that is, consists of "Key: value" pairs and has at least the mandatory fields (and maybe also check whether the email address listed looks like a valid address and not something @local or so). This would also catch other potential mistakes. The queue processing software uses a standard 'mail header' parser, which breaks parsing on the first newline, which happens to be before the intended content. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315538: dput doesn't refuse to operate on doubly-signed .changes
Jeroen van Wolffelaar wrote: > dput doesn't refuse to operate on doubly-signed .changes. But katie > will choke on those, and is not able to extract the Uploader, so the > uploader won't get any feedback. [...] > It's not large, but when it happens, there is no feedback on what > happened, as the upload queue processor does *not* fail on it but > reports success back, and then you get silence. What I'm missing here is why not fix the tools that don't give the right feedback rather than trying to patch every possible method of uploading new packages? I'd attack the problem at the source. Thijs signature.asc Description: This is a digitally signed message part
Bug#315538: dput doesn't refuse to operate on doubly-signed .changes
On Thu, Jun 23, 2005 at 05:53:47PM +0200, Thomas Viehmann wrote: > Hi Jeroen, > > thank you for your investigation of the issue and your resulting > suggestion. > I do think that this might be a good check to do and will consider > implementing it. > Do you happen to have any idea though how large this problem is? After > all, I don't think debsign allows creation of doubly-signed .changes. It's not large, but when it happens, there is no feedback on what happened, as the upload queue processor does *not* fail on it but reports success back, and then you get silence. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315538: dput doesn't refuse to operate on doubly-signed .changes
Hi Jeroen, thank you for your investigation of the issue and your resulting suggestion. I do think that this might be a good check to do and will consider implementing it. Do you happen to have any idea though how large this problem is? After all, I don't think debsign allows creation of doubly-signed .changes. Kind regards T. Jeroen van Wolffelaar wrote: > dput doesn't refuse to operate on doubly-signed .changes. But katie > will choke on those, and is not able to extract the Uploader, so the > uploader won't get any feedback. > > It'd be beneficial for all (uploaders, and ftpmasters who get a mail > when this happens) if dput would warn strongly when it detects a > .changes is signed twice. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315538: dput doesn't refuse to operate on doubly-signed .changes
Package: dput Severity: wishlist dput doesn't refuse to operate on doubly-signed .changes. But katie will choke on those, and is not able to extract the Uploader, so the uploader won't get any feedback. It'd be beneficial for all (uploaders, and ftpmasters who get a mail when this happens) if dput would warn strongly when it detects a .changes is signed twice. Steve Langasek confirmed this package was uploaded with dput. --Jeroen - Forwarded message from Debian Installer <[EMAIL PROTECTED]> - From: Debian Installer <[EMAIL PROTECTED]> To: Debian Installer <[EMAIL PROTECTED]> Subject: unixodbc_2.2.11-2_alpha+i386.changes REJECTED Message-Id: <[EMAIL PROTECTED]> Date: Thu, 23 Jun 2005 06:17:04 -0400 Rejected: unixodbc_2.2.11-2_alpha+i386.changes: parse error, can't grok: - -BEGIN PGP SIGNATURE-. === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. - End forwarded message - -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
