Re: proposed removal of Enigmail from jessie/LTS
On Tue 2019-01-22 14:44:50 -0500, Antoine Beaupré wrote: > I'm not sure we should remove *both* enigmail and thunderbird from > jessie. I understand there are problems with the a.m.o version, but then > that's somewhat outside of scope of LTS. It would seem rather unfair for > users of thunderbird that do *not* use enigmail to have their favorite > email client yanked away from them because a third-party plugin fails to > be maintainer correctly. > > Right now I'm leaning towards completely dropping support from Enigmail > in jessie, since the changes required are too far ranging to be > comfortable. I've yet to hear a specific concern about a known failure that derives from the backporting work that anarcat did. I know of several concrete failures that will result from users of Jessie pulling enigmail from a.m.o. telling jessie users that they should pull from a.m.o. is effectively doing them a disservice, if they think they're being supported. If i was responsible for maintaining jessie, i'd prefer to go the route of the backported fixes, but i don't have the capacity to spend a lot of time on jessie itself, so i guess my preferences should be weighed accordingly. --dkg signature.asc Description: PGP signature
Re: proposed removal of Enigmail from jessie/LTS
On Tue, Jan 22, 2019 at 02:44:50PM -0500, Antoine Beaupré wrote: > > I'm not sure we should remove *both* enigmail and thunderbird from > jessie. I understand there are problems with the a.m.o version, but then [..] > Right now I'm leaning towards completely dropping support from Enigmail > in jessie, since the changes required are too far ranging to be > comfortable. +1, there's certainly enough uses cases where Thunderbird is used without PGP. Cheers, Moritz
Re: proposed removal of Enigmail from jessie/LTS
On 2018-12-20 14:30:49, Daniel Kahn Gillmor wrote: > fwiw, i agree with jmm that encouraging users to upgrade to stable is > the best outcome here. The question is, what are we doing to the folks > who (for whatever reason) can't make that switch. > > On Thu 2018-12-20 17:01:30 +0100, Moritz Mühlenhoff wrote: >> If suddenly all kinds of core libraries are getting updated in jessie >> (with minimal testing) > > we're not talking about "all kinds of core libraries" -- we're talking > about a very selected subset. And i don't think we're talking about > "minimal testing", there has been a reasonable amount of testing. I > think we ought to consider this specific case, rather than trying to > make a systematized rule. > >> EOLing enigmail seems the only sensible option by far. > > the main issue with EOLing enigmail is that users will (instead of > upgrading to stable) typically just use the version from > addons.mozilla.org, which has both non-DFSG-free issues and > significantly scary behavior (downloading and silently executing > binaries from the web on the user's behalf). > > If we're EOLing thunderbird on jessie entirely, that'd be one thing (and > i'd be ok with it). But EOLing enigmail on its own sounds like a route > to trouble for enigmail users on jessie. So looking back at this problem again... I'm not sure we should remove *both* enigmail and thunderbird from jessie. I understand there are problems with the a.m.o version, but then that's somewhat outside of scope of LTS. It would seem rather unfair for users of thunderbird that do *not* use enigmail to have their favorite email client yanked away from them because a third-party plugin fails to be maintainer correctly. Right now I'm leaning towards completely dropping support from Enigmail in jessie, since the changes required are too far ranging to be comfortable. But I could be convinced otherwise. A. -- Il n'existe aucune limite sacrée ou non à l'action de l'homme dans l'univers. Depuis nos origines nous avons le choix: être aveuglé par la vérité ou coudre nos paupières. - [no one is innocent]
Re: proposed removal of Enigmail from jessie/LTS
On Thu, Dec 20, 2018 at 02:30:49PM -0500, Daniel Kahn Gillmor wrote: > we're not talking about "all kinds of core libraries" -- we're talking > about a very selected subset. Which are used by core system services like systemd, which makes them core libraries. > > EOLing enigmail seems the only sensible option by far. > > the main issue with EOLing enigmail is that users will (instead of > upgrading to stable) typically just use the version from > addons.mozilla.org, which has both non-DFSG-free issues and > significantly scary behavior (downloading and silently executing > binaries from the web on the user's behalf). EOLed packages are discontinued with an advisory advising users of the EOLed status, so it can explicitly warn about using the version from addons.mozilla.org. If users then still choose the other options, well than it's within their freedom. On a more general level; I'm not sure if there were prior discussions with Mozilla about that, but ideally addons.mozilla.org would flag addons which fetch/run additional code so that users can make an educated choice to opt-out. The current approach is only asking for crypto miners to hijack addons dependencies in the future... Cheers, Moritz
Re: proposed removal of Enigmail from jessie/LTS
On 2018-12-20 14:30:49, Daniel Kahn Gillmor wrote: > fwiw, i agree with jmm that encouraging users to upgrade to stable is > the best outcome here. The question is, what are we doing to the folks > who (for whatever reason) can't make that switch. > > On Thu 2018-12-20 17:01:30 +0100, Moritz Mühlenhoff wrote: >> If suddenly all kinds of core libraries are getting updated in jessie >> (with minimal testing) > > we're not talking about "all kinds of core libraries" -- we're talking > about a very selected subset. And i don't think we're talking about > "minimal testing", there has been a reasonable amount of testing. I > think we ought to consider this specific case, rather than trying to > make a systematized rule. > >> EOLing enigmail seems the only sensible option by far. > > the main issue with EOLing enigmail is that users will (instead of > upgrading to stable) typically just use the version from > addons.mozilla.org, which has both non-DFSG-free issues and > significantly scary behavior (downloading and silently executing > binaries from the web on the user's behalf). > > If we're EOLing thunderbird on jessie entirely, that'd be one thing (and > i'd be ok with it). But EOLing enigmail on its own sounds like a route > to trouble for enigmail users on jessie. Thanks both of you for your feedback. I'm running out of time until the holidays so I will personally let that one rest until January. The packages are on people.d.o and can be tested by anyone. I think it would be very useful if people would pursue that. Alternatively, we can just drop support for Enigmail in jessie, as I proposed in September. It just feels it's too bad to have wasted all that time only to give up when we're so close to the goal, only because of libgcrypt. But, as Emilio said, we coudln't have forseen those difficulties back then so maybe it's fair to just give up at this point. I would be worried about our users however... Have a nice holiday season, or congress for those of you with that privilege. ;) A. -- The price of reliability is the pursuit of the utmost simplicity. - C.A.R. Hoare
Re: proposed removal of Enigmail from jessie/LTS
fwiw, i agree with jmm that encouraging users to upgrade to stable is the best outcome here. The question is, what are we doing to the folks who (for whatever reason) can't make that switch. On Thu 2018-12-20 17:01:30 +0100, Moritz Mühlenhoff wrote: > If suddenly all kinds of core libraries are getting updated in jessie > (with minimal testing) we're not talking about "all kinds of core libraries" -- we're talking about a very selected subset. And i don't think we're talking about "minimal testing", there has been a reasonable amount of testing. I think we ought to consider this specific case, rather than trying to make a systematized rule. > EOLing enigmail seems the only sensible option by far. the main issue with EOLing enigmail is that users will (instead of upgrading to stable) typically just use the version from addons.mozilla.org, which has both non-DFSG-free issues and significantly scary behavior (downloading and silently executing binaries from the web on the user's behalf). If we're EOLing thunderbird on jessie entirely, that'd be one thing (and i'd be ok with it). But EOLing enigmail on its own sounds like a route to trouble for enigmail users on jessie. --dkg signature.asc Description: PGP signature
Re: proposed removal of Enigmail from jessie/LTS
On Wed, Dec 19, 2018 at 05:03:26PM +, Holger Levsen wrote: > I mostly worried that you didnt test all dependent packages and that we > essentially might break those when trying to support a package no > customer has expressed need for. But then I also suppose such breakage > could be fixed... But the very basic idea of a LTS release is to avoid the risk of breakage. If suddenly all kinds of core libraries are getting updated in jessie (with minimal testing) I'd need to run extensive tests when deploying this change sensibly and if such extensive tests are needed, I could just as well upgrade to stable. We'd never do such a change in a regular oldstable/stable either. EOLing enigmail seems the only sensible option by far. After all, there's a solid alternative if there's actually remaining Enigmail users on jessie; upgrading to Stretch. Cheers, Moritz
Re: proposed removal of Enigmail from jessie/LTS
Hi Antoine, On 19/12/2018 18:25, Antoine Beaupré wrote: > On 2018-12-19 17:03:26, Holger Levsen wrote: >> On Wed, Dec 19, 2018 at 11:40:07AM -0500, Antoine Beaupré wrote: >> [...] >> I've now also re-read this thread (for the 2nd time today..) and first >> I'd like to notice that all the concerns were only brought up in the >> last week, so it was definitly right from you to work on this for those >> months. Second, it now reads to me as if Emilio changed his mind after >> expressing concerns on Dec 14th, he indeed replied much more favorably >> on the 18th. > > Thanks for your message, I'm relieved and happy to get support from > you. :) I'm sorry if my comments caused your frustration. I think you have done an amazing job getting all this work done. I just think we need to try and balance the goal of supporting all packages that we can, versus the risk or causing regressions in important stuff. >> I mostly worried that you didnt test all dependent packages and that we >> essentially might break those when trying to support a package no >> customer has expressed need for. But then I also suppose such breakage >> could be fixed... > > So I was mostly concerned about libgcrypt dependencies, and in > particular cryptsetup, and smoke tests seems to go through okay > there, for what that's worth... cryptsetup is definitely one of the main rdeps. Also libgcrypt20 is used by systemd, ntfs-3g. There's also libssh, which is used by e.g. qemu, php-ssh2, libcurl... That doesn't mean we can't upgrade it. It just means it's an important package and the risk is higher due to its wide use and because of the extensive changes. Just need to be extra careful. >> and now we are back to square one :/ > > Not really. We're actually at square N-1, we just need to do that one > final jump to get in the "let's actually support that newer version" > game. :p > > Should we pursue this? Are there any other packages that should be > tested? > > Would love other people's opinion as well... Maybe some of the other rdeps. libssh test suite (if it has one), systemd... However in the end it will come down to whether you feel confident to push that out or think it's better to stay put. Whatever you decide, I'll do my best to help in any way I can. Cheers, Emilio
Re: proposed removal of Enigmail from jessie/LTS
On 2018-12-19 17:03:26, Holger Levsen wrote: > On Wed, Dec 19, 2018 at 11:40:07AM -0500, Antoine Beaupré wrote: > [...] > I've now also re-read this thread (for the 2nd time today..) and first > I'd like to notice that all the concerns were only brought up in the > last week, so it was definitly right from you to work on this for those > months. Second, it now reads to me as if Emilio changed his mind after > expressing concerns on Dec 14th, he indeed replied much more favorably > on the 18th. Thanks for your message, I'm relieved and happy to get support from you. :) > I mostly worried that you didnt test all dependent packages and that we > essentially might break those when trying to support a package no > customer has expressed need for. But then I also suppose such breakage > could be fixed... So I was mostly concerned about libgcrypt dependencies, and in particular cryptsetup, and smoke tests seems to go through okay there, for what that's worth... > and now we are back to square one :/ Not really. We're actually at square N-1, we just need to do that one final jump to get in the "let's actually support that newer version" game. :p Should we pursue this? Are there any other packages that should be tested? Would love other people's opinion as well... A. -- Pour marcher au pas d'une musique militaire, il n'y a pas besoin de cerveau, une moelle épinière suffit. - Albert Einstein
Re: proposed removal of Enigmail from jessie/LTS
On Wed, Dec 19, 2018 at 11:40:07AM -0500, Antoine Beaupré wrote: [...] > Both Emilio and Daniel supported the idea of pushing the GnuPG 2.1 > backport. So I did that and spent most of my LTS time for december > working on the GnuPG 2.1 upload. > > I was just about to finalize the upload, based on Emilio's review of the > patchset, when I read your message. Now I'm at a loss at what to do with > this project. > > Obviously, it would be easy to upload a new debian-security-support > package to declare Enigmail dead. But it would have been a much more > efficient use of our time if we would have decided that back in > september when I first brought up the idea. > > I find this situation rather frustrating, to say the least. I understand > people don't always have time to read all messages and respond promptly > to proposals, but I think I've given that one plenty of time, so it's a > little difficult to just drop everything now, after so much work has > been done to finalize that backport. I very much understand your frustration and I don't think you should have done this work in vain/uncompensated, however sometimes it's only possible after the work to determine that an upgrade is too risky. I've now also re-read this thread (for the 2nd time today..) and first I'd like to notice that all the concerns were only brought up in the last week, so it was definitly right from you to work on this for those months. Second, it now reads to me as if Emilio changed his mind after expressing concerns on Dec 14th, he indeed replied much more favorably on the 18th. I mostly worried that you didnt test all dependent packages and that we essentially might break those when trying to support a package no customer has expressed need for. But then I also suppose such breakage could be fixed... and now we are back to square one :/ -- 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
