Re: the way to enigmail: gnupg 2.1 backport considerations
On Tue 2018-11-20 15:47:00 +, Ben Hutchings wrote: > On Tue, 2018-11-20 at 10:28 -0500, Antoine Beaupré wrote: >> On 2018-11-20 15:19:45, Ben Hutchings wrote: >> > On Mon, 2018-11-19 at 15:48 -0500, Antoine Beaupré wrote: > [...] >> > > I think this is overengineered. I still haven't heard exactly what the >> > > problem would be with upgrading those libraries. They are present in >> > > jessie-backports and presumably well tested. >> > [...] >> > >> > Those updated library packages are installed and used by people that >> > specifically choose to use GnuPG 2.1 in jessie. I don't think we can >> > assume they are well-tested in conjunction with GnuPG 1.4. >> >> My understanding is that GnuPG 1.4 does not use those libraries at all, >> and from what I can tell, gpg 1.4 does not link against them either. > > Oh! I don't know why I thought it did. Then this does seem like a > reasonable approach. Just confirming Anarcat's comment here. GnuPG's classic branch (1.4.x) is a monolithic build, and does not depend on any of the libraries in question. Those libraries are used by GnuPG 2.0.x and later. The main place where you'll find them used is: * things that use gcrypt directly (e.g. cryptsetup) * things that use gpgme (e.g. gmime) As Anarcat suggests, i believe that upstream intends the lack of an SONAME bump to mean that they should be cleanly upgradable. I'm not super confident in upstream's ability to maintain a stable API, sadly. For example, some of the libraries in question -- like gcrypt -- do a lot with string-passing between the main application and the library, which means that they don't expose API changes via function call entrypoints, which is how debian is best at doing simple API tracking (e.g. .symbols files). There are also data structures in some libraries (like gpgme) that are exposed directly, but that the user is expected to receive pointers to from the library, but not to directly instantiate (and yes, sometimes those data structures do grow over time, though i don't think i've ever seen them actually change in a backward-incompatible way across a release). The library documentation is often sparse about which data structures the users are expected to avoid instantiating directly, though upstream is usually pretty good about providing feedback to developers who ask questions on the gnupg-de...@gnupg.org mailing list. All that said, i don't think that upgrading jessie to the versions of these libraries that are in debian stretch will break jessie. I do wish we had more substantive autopkgtest-style coverage in jessie, so that we could feel more confident about this, but i don't think we currently do. --dkg signature.asc Description: PGP signature
Re: unclaiming packages claimed for 3 weeks or more (Re: november report)
Hi, El 20/11/18 a las 16:17, Holger Levsen escribió: > Hi, > > On Mon, Nov 19, 2018 at 06:50:16PM -0500, Antoine Beaupré wrote: > > Automatic unclaimer > > --- > > > > After an internal discussion about work procedures, a friend pointed me > > at the [don't lick the cookie][6] article which I found really > > interesting. The basic idea is that our procedure for work distribution > > is based on "claims" which mean some packages remain claimed for > > extended periods of time. First of all, thanks for working on this! … > -qemu (Santiago) > +qemu > NOTE: 20181026: no fix yet for recent dsa issues, but start working on > NOTE: pending no-dsa issues > Technically correctly unclaimed (as last edit was 26 days ago), however > given the notes I think this should stay as it is. Currently building with most of patches (I still have to see if it's possible to fix two CVEs). Sorry for the delay, and for not updating dla-needed.txt Cheers, -- S signature.asc Description: PGP signature
Re: unclaiming packages claimed for 3 weeks or more (Re: november report)
Hi Hugo, On Tue, Nov 20, 2018 at 05:46:21PM +0100, Hugo Lefeuvre wrote: > > -libav (Hugo Lefeuvre) > > +libav > > AFAICS this is a legit unclaim. Hugo, would you mind to unclaim this? > I don't mind. This is probably the best thing to do. ok, done, thanks. And: feel free to reclaim this package at any time (when you have time/stuff to work on it). > I kept this claimed for the following reasons: I don't think you *needed* to explain why, I'm (and was) sure you had good reasons. Also we want automatic unclaiming to save everyone from explaining, feeling bad, blocking each other. Automatic cookie unlicking FTW! > + I have few reproducers which I am not allowed to redistribute publicly. > They are not 'working' directly and investigations are very > costly, usually ~8-10h/CVE which did not fit in my available time these > last months. > > + I was handling the contact with Diego Biurrun, a libav developer who > taking part to the libav maintainance in Debian LTS a while ago. For > some reasons he had to stop and it is unlikely that he will start > again. > > + I am still interested in libav work. that's all very cool. Keep up the good work! (You could also have edit a NOTE saying something light aand kept the claim.) > > -liblivemedia (Hugo Lefeuvre) > > +liblivemedia > > last NOTE: *doesnt have a date to it* > > and there's not Last-Update. > > Not sure what to do with it, Hugo? > I have released the update 20mn ago ;) great, thanks! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: unclaiming packages claimed for 3 weeks or more (Re: november report)
Hi Holger, > So I ran it asking it to unclaim packages which didnt see activity in > dla-needed.txt for more than 3 weeks. These are the results from running > ./bin/review-update-needed --lts --unclaim 1814400 > > -libav (Hugo Lefeuvre) > +libav > last NOTE: 20180529: Just contacted some of the CVE reporters to ask for the > reproducers, CC-ed team ML. > that's Last-Update: 2018-09-22 12:04 (59 days ago) > AFAICS this is a legit unclaim. Hugo, would you mind to unclaim this? I don't mind. This is probably the best thing to do. I kept this claimed for the following reasons: + I have few reproducers which I am not allowed to redistribute publicly. They are not 'working' directly and investigations are very costly, usually ~8-10h/CVE which did not fit in my available time these last months. + I was handling the contact with Diego Biurrun, a libav developer who taking part to the libav maintainance in Debian LTS a while ago. For some reasons he had to stop and it is unlikely that he will start again. + I am still interested in libav work. > -liblivemedia (Hugo Lefeuvre) > +liblivemedia > last NOTE: *doesnt have a date to it* > and there's not Last-Update. > Not sure what to do with it, Hugo? I have released the update 20mn ago ;) cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
unclaiming packages claimed for 3 weeks or more (Re: november report)
Hi, On Mon, Nov 19, 2018 at 06:50:16PM -0500, Antoine Beaupré wrote: > Automatic unclaimer > --- > > After an internal discussion about work procedures, a friend pointed me > at the [don't lick the cookie][6] article which I found really > interesting. The basic idea is that our procedure for work distribution > is based on "claims" which mean some packages remain claimed for > extended periods of time. > > [6]: https://www.benday.com/2016/10/21/scrum-dont-lick-the-cookie/ > > For some packages it makes sense: the kernel updates, for example, have > been consistently and dilligently performed by Ben Hutchings for as long > as I remember, and I myself would be very hesitant in claiming that > package myself. In that case it makes sense that the package remains > claimed for a long time. > > But for some other packages, it's just an oversight: you claim the > package, work on it for a while, then get distracted by more urgent > work. It happens all the time, to everyone. The problem is then that the > work is stalled and, in the meantime, other people looking for work are > faced with a long list of claimed packages. > > In theory, we are allowed to "unclaim" a package that's been idle for > too long, but as the article describes, there's a huge "emotional cost" > associated with making such a move. > > So I looked at automating this process and [unclaim packages > automatically][7]. This was originally rejected by the security team > which might have confused the script implementation with a separate > [proposal][8] to add a cronjob on the security tracker servers to > automate the process there. > > [7]: > https://salsa.debian.org/security-tracker-team/security-tracker/merge_requests/23 > [8]: > https://salsa.debian.org/security-tracker-team/security-tracker-service/merge_requests/2 > > After some tweaking and bugfixing, I believe the script is ready for use > and our new LTS coordinator will give it a try, in what I would describe > as a "manually triggered automatic process" while with figure out if the > process will work for us. So I ran it asking it to unclaim packages which didnt see activity in dla-needed.txt for more than 3 weeks. These are the results from running ./bin/review-update-needed --lts --unclaim 1814400 -libav (Hugo Lefeuvre) +libav last NOTE: 20180529: Just contacted some of the CVE reporters to ask for the reproducers, CC-ed team ML. that's Last-Update: 2018-09-22 12:04 (59 days ago) AFAICS this is a legit unclaim. Hugo, would you mind to unclaim this? -liblivemedia (Hugo Lefeuvre) +liblivemedia last NOTE: *doesnt have a date to it* and there's not Last-Update. Not sure what to do with it, Hugo? -linux (Ben Hutchings) +linux and -linux-4.9 (Ben Hutchings) +linux (here I think I would like to be able to whitelist this as Ben currently always takes these packages.) -nsis (Thorsten Alteholz) +nsis last NOTE: 20181110: waiting for email answer so here the script is buggy, this should not have been unclaimed! -openjpeg2 (Hugo Lefeuvre) +openjpeg2 last NOTE: *doesnt have a date to it* still there is last-update in the output and it says "Last-Update: 2018-11-19 19:02" so I believe the script is buggy. -qemu (Santiago) +qemu NOTE: 20181026: no fix yet for recent dsa issues, but start working on NOTE: pending no-dsa issues Technically correctly unclaimed (as last edit was 26 days ago), however given the notes I think this should stay as it is. -symfony (Thorsten Alteholz) +symfony NOTE: 20181110: patches ready, struggling with test suite, waiting for email another bug in the script, this should not have been unclaimed. Conclusion: the script has potential but is still too buggy ;) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: testing openssl for Jessie LTS
Hi Thorsten, Am 19.11.18 um 20:04 schrieb Thorsten Alteholz: > Hi everybody, > > I uploaded version 1.0.1t-1+deb8u10 of openssl to: > > https://people.debian.org/~alteholz/packages/jessie-lts/openssl/ > > Please give it a try and tell me about any problems you met. [...] I will test it tomorrow and report back. Regards, Markus signature.asc Description: OpenPGP digital signature
feedback on review-update-needed --lts --unclaim (Re: november report)
hi,
this reply is mostly about using the tool itself, see below. I will now write
another mail about the results from using it...
On Mon, Nov 19, 2018 at 06:50:16PM -0500, Antoine Beaupré wrote:
> Automatic unclaimer
> ---
>
> After an internal discussion about work procedures, a friend pointed me
> at the [don't lick the cookie][6] article which I found really
> interesting. The basic idea is that our procedure for work distribution
> is based on "claims" which mean some packages remain claimed for
> extended periods of time.
>
> [6]: https://www.benday.com/2016/10/21/scrum-dont-lick-the-cookie/
>
> For some packages it makes sense: the kernel updates, for example, have
> been consistently and dilligently performed by Ben Hutchings for as long
> as I remember, and I myself would be very hesitant in claiming that
> package myself. In that case it makes sense that the package remains
> claimed for a long time.
>
> But for some other packages, it's just an oversight: you claim the
> package, work on it for a while, then get distracted by more urgent
> work. It happens all the time, to everyone. The problem is then that the
> work is stalled and, in the meantime, other people looking for work are
> faced with a long list of claimed packages.
>
> In theory, we are allowed to "unclaim" a package that's been idle for
> too long, but as the article describes, there's a huge "emotional cost"
> associated with making such a move.
>
> So I looked at automating this process and [unclaim packages
> automatically][7]. This was originally rejected by the security team
> which might have confused the script implementation with a separate
> [proposal][8] to add a cronjob on the security tracker servers to
> automate the process there.
>
> [7]:
> https://salsa.debian.org/security-tracker-team/security-tracker/merge_requests/23
> [8]:
> https://salsa.debian.org/security-tracker-team/security-tracker-service/merge_requests/2
>
> After some tweaking and bugfixing, I believe the script is ready for use
> and our new LTS coordinator will give it a try, in what I would describe
> as a "manually triggered automatic process" while with figure out if the
> process will work for us.
first, thanks your work and the nice summary of it, Antoine!
second, I ran the script now and got results, running it as
"./bin/review-update-needed --unclaim" it removed these entries:
Package: openjpeg2
Claimed-By: luciano
Claimed-Date: 2018-02-04 21:47 (288 days ago)
Package: 389-ds-base
Claimed-By: fw
Claimed-Date: 2016-10-18 21:26 (762 days ago)
Last-Update: 2018-07-12 21:25 (130 days ago)
Package: libxml2
Claimed-By: carnil
Claimed-Date: 2018-09-02 19:46 (78 days ago)
which interestingly 'hit the spot' we've previously discussed internally on the
freexian-LTS list: while we can define rules for paid contributors ('after X
weeks
we will unclaim stuff which has been claimed but not finished') we cannot really
impose such rules on voluntary LTS contributors, like luciano, fw and carnil
here.
So, luciano, fw and carnil: are you ok with unclaiming those packages? Or is
there
some other course of action you would suggest here?
Then... I realised I need to run "./bin/review-update-needed --unclaim
--lts", doh and you can basically ignore my last two paragraphs (because
they dont apply to LTS, but I left them as the general question still
stands...
So, third, what did "./bin/review-update-needed --unclaim --lts" do? Too
much, so I ran (in a sid schroot where I have python3-humanfriendly
installed) this: "schroot -- ./bin/review-update-needed --lts --unclaim 3w"
and got:
[output and]
Traceback (most recent call last):
File "./bin/review-update-needed", line 129, in
args.quiet or print("Claimed-By: {}".format(entry['claimed-by']))
UnicodeEncodeError: 'ascii' codec can't encode character '\xe1' in position 24:
ordinal not in range(128)
(This only happens if I run ./bin/review-update-needed in schroot.)
However no changes were made.
Fourth, the order of entries in the output and in data/dla-needed.txt is
different, which is confusing and makes it harder to find entries, could
that be fixed?
Fifth, if a package is unclaimed, it would be good to include this in
the package related output (and not just in the summary in the end), so
instead of for example:
Package: icecast2
Claimed-By: Abhijith PA
Claimed-Date: 2018-11-04 11:25 (16 days ago)
Last-Update: 2018-11-06 09:46 (14 days ago)
it would be nicer if the output were
Package: icecast2
Claimed-By: Abhijith PA
Claimed-Date: 2018-11-04 11:25 (16 days ago)
Last-Update: 2018-11-06 09:46 (14 days ago)
Unclaimed because last update was more than $timespan ago.
Six, I ran "./bin/review-update-needed --lts --unclaim 1814400" on
stretch and got useful output which I will summarize in another mail,
so that we have one thread about improving the tool and another about
unclaiming specific packages.
--
cheers,
Holger
---
Re: the way to enigmail: gnupg 2.1 backport considerations
On Tue, 2018-11-20 at 10:28 -0500, Antoine Beaupré wrote: > On 2018-11-20 15:19:45, Ben Hutchings wrote: > > On Mon, 2018-11-19 at 15:48 -0500, Antoine Beaupré wrote: [...] > > > I think this is overengineered. I still haven't heard exactly what the > > > problem would be with upgrading those libraries. They are present in > > > jessie-backports and presumably well tested. > > [...] > > > > Those updated library packages are installed and used by people that > > specifically choose to use GnuPG 2.1 in jessie. I don't think we can > > assume they are well-tested in conjunction with GnuPG 1.4. > > My understanding is that GnuPG 1.4 does not use those libraries at all, > and from what I can tell, gpg 1.4 does not link against them either. Oh! I don't know why I thought it did. Then this does seem like a reasonable approach. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Re: automating process for publishing DLAs on the website
On Mon, Nov 19, 2018 at 07:07:26PM -0500, Antoine Beaupré wrote: > The process broke down a while back, and reasons don't matter. We need > to figure out how to fix this. > > So I opened #859122 to import the missing DLAs and I've made good > progress. > > But I've opened this bug report (#859123) to fix the process. So far, > the idea we had was to make LTS contributors submit a patch to the > website as part of the DLA publication process. You'd run the little > "parse-dla.pl" script which would create two files in the webwml git > repository, separate from the security tracker! that's where the > debian.org website lives.. Then you'd commit those and send a merge > request to the project (or just push if you have the rights). The > webmaster folks seemed to be open to grant us access to the repo to > remove friction as well.. > > How does that sound? sounds very good to me. thanks for your work on this so far! > Another thing I thought we could do would be to hook that script into a > mailbox that would receive mail from the debian-lts-announce list and > automatically publish the results into git. But so far my efforts at > automating things on Debian infrastructure have mostly failed, so I'm > not sure it's the way to go. Besides, the parse-dsa.pl script isn't > exactly solid, and don't like the idea of parsing arbitrary input like > this without a human oversight. But it would certainly reduce friction > to a minimum, which I like. I better like your above proposal than generating data from parsing mails which we have sent previously. So I've just requested webwml access from the debian-www folks. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: the way to enigmail: gnupg 2.1 backport considerations
On 2018-11-20 15:19:45, Ben Hutchings wrote:
> On Mon, 2018-11-19 at 15:48 -0500, Antoine Beaupré wrote:
>> On 2018-11-13 22:02:45, Ben Hutchings wrote:
>> > On Tue, 2018-11-13 at 12:31 -0500, Daniel Kahn Gillmor wrote:
>> > > On Mon 2018-11-12 15:16:39 -0500, Antoine Beaupré wrote:
>> > >
>> > > > * libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)
>> > >
>> > > libgcrypt is not a part of GnuTLS. GnuTLS has used nettle instead of
>> > > gcrypt for years. gcrypt is more properly "part of GnuPG" than anything
>> > > else.
>> > >
>> > > basically, all of these libraries are gnupg libraries.
>> > >
>> > > It's a little bit distressing that upstream's attempt to split them out
>> > > as distinct libraries (which i think was intended to make them more
>> > > useful to other consumers) might be a roadblock on the way to updating
>> > > GnuPG itself.
>> > >
>> > > Ben's suggestion of shipping them in a non-default location ("vendor
>> > > bundling"?) sounds pretty dubious to me -- i wouldn't want to reason
>> > > about (let alone vouch for) the upgrade path from such a hybridized
>> > > variant of jessie to standard debian stretch myself.
>> >
>> > I was thinking that those libraries would be included in the same
>> > binary package as /usr/bin/gpg2 and other executables, which would all
>> > have a run-path set. No-one should need to set LD_LIBRARY_PATH so no
>> > other executables would use those libraries, and the libraries would be
>> > removed when the executables that use them are removed or replaced.
>> >
>> > Since gnupg2 actually spreads executables across multiple binary
>> > packages, I realise the libraries would have to be an additional binary
>> > package and that would remain after an upgrade. But it would be
>> > harmless cruft that "apt autoremove" would deal with.
>> >
>> > (I assume that GnuPG 2.1 would be packaged as "gnupg2", replacing GnuPG
>> > 2.0 since that is no longer supported upstream. If not then I do see a
>> > problem of how to make, say, gnupg2.1 in jessie upgrade to gnupg2 in
>> > stretch. But that's independent of the library issue.)
>>
>> I think this is overengineered. I still haven't heard exactly what the
>> problem would be with upgrading those libraries. They are present in
>> jessie-backports and presumably well tested.
> [...]
>
> Those updated library packages are installed and used by people that
> specifically choose to use GnuPG 2.1 in jessie. I don't think we can
> assume they are well-tested in conjunction with GnuPG 1.4.
My understanding is that GnuPG 1.4 does not use those libraries at all,
and from what I can tell, gpg 1.4 does not link against them either.
A.
--
On reconnait la grandeur et la valeur d'une nation à la façon dont
celle-ci traite ses animaux.
- Mahatma Gandhi
Re: the way to enigmail: gnupg 2.1 backport considerations
On Mon, 2018-11-19 at 15:48 -0500, Antoine Beaupré wrote:
> On 2018-11-13 22:02:45, Ben Hutchings wrote:
> > On Tue, 2018-11-13 at 12:31 -0500, Daniel Kahn Gillmor wrote:
> > > On Mon 2018-11-12 15:16:39 -0500, Antoine Beaupré wrote:
> > >
> > > > * libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)
> > >
> > > libgcrypt is not a part of GnuTLS. GnuTLS has used nettle instead of
> > > gcrypt for years. gcrypt is more properly "part of GnuPG" than anything
> > > else.
> > >
> > > basically, all of these libraries are gnupg libraries.
> > >
> > > It's a little bit distressing that upstream's attempt to split them out
> > > as distinct libraries (which i think was intended to make them more
> > > useful to other consumers) might be a roadblock on the way to updating
> > > GnuPG itself.
> > >
> > > Ben's suggestion of shipping them in a non-default location ("vendor
> > > bundling"?) sounds pretty dubious to me -- i wouldn't want to reason
> > > about (let alone vouch for) the upgrade path from such a hybridized
> > > variant of jessie to standard debian stretch myself.
> >
> > I was thinking that those libraries would be included in the same
> > binary package as /usr/bin/gpg2 and other executables, which would all
> > have a run-path set. No-one should need to set LD_LIBRARY_PATH so no
> > other executables would use those libraries, and the libraries would be
> > removed when the executables that use them are removed or replaced.
> >
> > Since gnupg2 actually spreads executables across multiple binary
> > packages, I realise the libraries would have to be an additional binary
> > package and that would remain after an upgrade. But it would be
> > harmless cruft that "apt autoremove" would deal with.
> >
> > (I assume that GnuPG 2.1 would be packaged as "gnupg2", replacing GnuPG
> > 2.0 since that is no longer supported upstream. If not then I do see a
> > problem of how to make, say, gnupg2.1 in jessie upgrade to gnupg2 in
> > stretch. But that's independent of the library issue.)
>
> I think this is overengineered. I still haven't heard exactly what the
> problem would be with upgrading those libraries. They are present in
> jessie-backports and presumably well tested.
[...]
Those updated library packages are installed and used by people that
specifically choose to use GnuPG 2.1 in jessie. I don't think we can
assume they are well-tested in conjunction with GnuPG 1.4.
Ben.
--
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.
signature.asc
Description: This is a digitally signed message part
Re: How to handle undetermined
Hi Ola, On Sun, Nov 18, 2018 at 10:30:16PM +0100, Ola Lundqvist wrote: > > > What I did was to check CVE-2016-10729 and my conclusion that I cannot > > > reproduce the problem. > > can you reproduce the bug in sid or stretch? > I have not tried, but I doubt I will succeed. I think the same security > measurements are applicable also in sid and stretch. > I'm suspecting that the necessary thing needed to exploit this is if anyone > have login permission to the backup user. But you cannot login to that user > on a Debian machine. well, (AIUI) for that you need to find another bug in amanda (or some tool amanda is using, like cron, or whatever, eg a totally unrelated root exploit), so that you then can get access to uid backup, and then you can exploit CVE-2016-10729 to compromise amanda clients. I dont think the fact that you cannot login as backup is a viable protection. > > but only do this if you are really sure, else leave it at undetermined. > I'm not 100% sure yet so I'll leave it as is for now. :-) I agree thats better. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
