Re: [PATCH v2 2/3] git-send-email: die on invalid smtp_encryption

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Apr 12 2021, Drew DeVault wrote:

> On Sun Apr 11, 2021 at 3:56 PM EDT, Ævar Arnfjörð Bjarmason wrote:
>> I suggest we don't compromise and just go with whatever you're OK with :)
>
> Well, if you're giving me an opportunity to not drag this out into a
> multi-phase rollout, then I'll take it :)

Just to be clear even if I was insisting on that I'm still just one guy
on the ML reviewing your patch.

As a first approximation the opinion of regular contributors counts for
more when the topic is some tricky interaction of code they wrote/are
familiar with.

In this case we're just discussing the general interaction of security,
optional switches, software versioning and how SMTP servers in the wild
work.

I'd think someone who e.g. needs to regularly deal with SMTP servers in
the wild would have a much better idea of those trade-offs than someone
(like me) who happens to have some existing patches in git.git to
git-send-email.perl.

> Another option is to forbid an unknown value (which is almost certainly
> (1) wrong and (2) causing users to unexpectedly use plaintext when they
> expected encryption), file a CVE, and pitch it as a security fix - then
> we can expect a reasonably quick rollout of the change to the ecosystem
> at large.

I think anyone would agree that in retrospect "unknown is plaintext" for
the "what encryption do you want" option is at best a something
approaching a shotgun to your foot of a UI pattern.

But I think it falls far short of a CVE. We *do* prominently document
it, a potential CVE would be if we had silent degration to plaintext
(well, in a mode whose inherent workings aren't to be vulnerable to that
attack, as STARTTLS is...).

FWIW since my upthread <87zgy4egtp.fsf@evledraar.gmail.com> I tried
sending mail through GMail's plain-text smtp gateway as an authenticated
user.

Testing with:

    nc smtp.gmail.com 25
    openssl s_client -connect smtp.gmail.com:465

It will emit a 530 if you try to AUTH in plain-text (telling you to use
STARTTLS), it will also only say "AUTH" in the EHLO response to the
latter.

And indeed Net::SMTP picks up on this, and doesn't even send your
user/password:
https://metacpan.org/release/libnet/source/lib/Net/SMTP.pm#L169

So this hypothetical degradation of the connection and sending auth over
plain-text I suggested in upthread #3 seems to mostly/entirely be a
non-issue as far as e.g. accidentally sending your password on some open
WiFi network goes due to a local misconfiguration.

As long as the SMTP server is functional enough to say it doesn't
support AUTH on plain-text you'll be OK. I'm assuming that these days
with the push for "SSL everywhere" most/all big providers/MTAs have
moved away from supporing plain-text auth by default.