[Popcon-developers] Bug#729097: enabled by default encryption breaks multi-server submission unless they share the same keyo
On Sun, 10 Nov 2013, Bill Allombert wrote:
> > For NeuroDebian we just made use of the feature that SUBMITURLS could list
> > multiple collection sites. With 1.60 encrypt default 'maybe' enables
> > compression using popcon.debian.org key thus breaking processing upon receival
> > by neuro.debian.net's site which doesn't have the key available.
> It is discourageing nobody says anything during the long comment period and
> now you report this.
yikes... I am sorry that my mortal perception system has managed to miss
the discussion happening on one of the dozen public mailing lists I am
subscribed to. I will adjust my BCI and subscribe to popcon-developers
as well (although I consider myself just a user here).
> > What resolution would you recommend?
> > - disabling encryption on such setups (would require a round of upgrades on
> > neurodebian installations.
> This is the only option if neuro.debian.net is not able to process
> encrypted emails.
neuro.debian.net is able to process encrypted emails but cannot
process emails encrypted by 0xFC86A020 since it doesn't have it.
Disabling of encryption would be somewhat counterproductive given you
consider encryption important.
> > - asking/getting/using your private GPG key you use for encryption?
> No, thought I could occasionally decrypt your files, it is not a long term
> solution.
I know. But it could provide a short term workaround I would
appreciate. Yesterday's processing cron job reported 6 reports it had
to decrypt. If it is a good mean, it would be ~40 altogether in a week
which would constitute around 6% of submissions we receive for
neuro.debian.net . So now while presenting Debian at our NeuroDebian
booth at SfN 2013 in the next 4 days I would just need to avoid
showing our popcon stats, or to say that 'there is a bug' leading to the
late dip... if it starts going back up with reports from 1.60 -- I could
at least state that we have addressed it.
> > - anything else for a quick workaround?
> > I guess ideal "fix" would be to be able to control encryption options (KEYRING,
> > KEYID, ENCRYPT) per each of submiturl's... heh heh
> ENCRYPT should be global because it does not make sense to send
> the data in clear to some hosts and encrypted to the others.
concur
> On the other hand, gpg allows to encrypt with several keys at once, so
> we should allow KEYRING and KEYID to be lists of KEYRING/KEYID.
indeed -- a good idea! Should I try to elaborate such a patch or you
are on top of it?
--
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Reply to: