Re: proposed removal of Enigmail from jessie/LTS

2019-01-22 Thread Daniel Kahn Gillmor
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

2019-01-22 Thread Ben Hutchings
On Tue, 2019-01-22 at 14:44 -0500, Antoine Beaupré wrote:
[...]
> 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 agree with you.  All the options are bad, but this seems to be the
least bad.

Ben.

> But I could be convinced otherwise.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere.
 - Anne Morrow Lindberg




signature.asc
Description: This is a digitally signed message part


Re: proposed removal of Enigmail from jessie/LTS

2019-01-22 Thread Moritz Muehlenhoff
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

2019-01-22 Thread Antoine Beaupré
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

2018-12-21 Thread Moritz Mühlenhoff
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

2018-12-21 Thread Antoine Beaupré
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

2018-12-20 Thread Daniel Kahn Gillmor
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

2018-12-20 Thread Moritz Mühlenhoff
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

2018-12-19 Thread Antoine Beaupré
On 2018-12-19 21:22:21, Emilio Pozuelo Monfort wrote:
> 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.

You're right. Sorry I might have overreacted - I am going through some
intense family issues right now and I might be a little jittery. :)

>>> 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.

Right.

>>> 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.

That's great! :) Unfortunately I'm running out of time this month - I
have a measly 2-3h left this month and holidays are coming up so I don't
know if I'll be able to complete this before the new year.

A.
-- 
Celui qui ne connaît pas l'histoire est condamné à la revivre.
- Karl Marx



Re: proposed removal of Enigmail from jessie/LTS

2018-12-19 Thread Emilio Pozuelo Monfort
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

2018-12-19 Thread Antoine Beaupré
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

2018-12-19 Thread Holger Levsen
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