bad keys result in no response on ppa uploads

[Robert Collins]

If we know the ppa the upload was target at we could put a notification
on the web page there; a single field (not one per failure), and no
email sent would:
 - allow users to discover it. (In fact we could document that they
should look there for other things too)
 - not be badly spammable - multiple annoying uploads would just
   coalesce into a single notification whenever the ppa owners happened
   to pop by

 affects launchpad

IRC snippet from discussion:

18:53 < tohms> strange ... tried yesterday evening to upload ... upload
self was fine but no mail and no package ... in both of my ppa ... tried
today again ... same matter
18:55 < cprov> tohms: it looks like a gpg key problem (no mail back).
What's the source name ?
18:56 < tohms> absolutely ... source is splashy_0.3.13-3ubuntu2
18:58 < cprov> tohms: FatalUploadError: GPG verification of
splashy_0.3.13-3ubuntu2_source.changes failed: Verification failed 3
times: ["(7, 9, 'No public key')", "(7, 9, 'No public key')", "(7, 9,
'No public
               key')"]
18:59 < tohms> damn ... why didn't I get this as an email notification?
19:00 < tohms> i've forgotten that I renewd my key ... thx for help!
19:03 < cprov> tohms: for the meantime, remember that 'no-email within
10 minutes' == 'your gpg key setup in LP has issues'
19:03 < cprov> tohms: no worries, sorry for the inconvenience, we are
working on a fix.
19:04 < tohms> at least you could help me now :)
19:04 < cprov> sure.
19:18 < lifeless> cprov: we could show something on the ppa page
19:18 < lifeless> 'uploads recently rejected without notification'
19:19 < cprov> lifeless: if we avoid to notify people when we can't
authenticate the changesfiles, I doubt we would like to store that
information in the DB
19:20 < cprov> lifeless: anyone could easily inject an annoying number
of rejected uploads in someone else PPA.
19:20 < lifeless> cprov: just thinking it would let them answer the
problem without you haveing to read a log
19:20 < lifeless> cprov: so limit it to one notification

Related: OOPS-1866PPA1221

[Celso Providelo (cprov)]

There is a quick set of checks that we could perform before finishing the upload session that would allow us to spot problems like that earlier and be able to warn the user immediately:

1. There is a .changes;
2. Its signature is good and known by LP;
3. The .changes is parseable;

If those 2 checks pass, there will be always a notification after the upload is processed (later) if any of them fail the upload session should be terminated with an error, which is handled by dput (and can be improved later).

This approach fits the current FTP media and will also work when and if we migrate to SSH media.

[Michael Nelson (michael.nelson)]

This would also address packages with expired keys, where currently we only detect this during processing: OOPS-1598PPA4.

[John Pye (jdpipe)]

As an interim measure, perhaps 'dput' could be patched so that when the upload target is a 'ppa:', the message returned to the user could be something more like "Upload completed; check Launchpad for possible errors/warnings"...

Currently, dput is providing false feedback claiming 'success' but this is often not going to be success from the user's perspect, eg if they

* have wrong gpg keys
* upload a bin package instead of a src package
* do something else they're not allowed to do (what other possibilities are there?)

Ideally the feedback would be provided via the output of 'dput' but if there are reasons why that's no doable then at least dputs claims of success should be watered down a bit.

[Julian Edwards (julian-edwards)]

Ok so I have a fix that works, which is based on another branch that's currently landing which is a brand new ftp server based on twisted.

The output you get from dput looks like this:

Uploading to dogfood (via ftp to dogfood.launchpad.net):
  Uploading hello_2.5-1ubuntu1.dsc: done.
  Uploading hello_2.5-1ubuntu1.diff.gz: done.
  Uploading hello_2.5-1ubuntu1_source.changes: 1k/2k550 ('Changes file must be signed with a valid GPG signature: Verification failed 3 times: ["(7, 8, u\'Bad signature\')", "(7, 8, u\'Bad signature\')", "(7, 8, u\'Bad signature\')"] ',): Permission denied.
Note: This error might indicate a problem with your passive_ftp setting.
      Please consult dput.cf(5) for details on this configuration option.

which should be enough for anyone to realise they've cocked up the signatures.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r12470 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12470>.

[Robert Collins (lifeless)]

Pending downtime to activate.

[Robert Collins (lifeless)]

We've had to rollback.

[William Grant (wgrant)]

See bug #733033 for the issue that forced the rollback.

[William Grant (wgrant)]

This was redeployed in the partial downtime a few hours ago.