Re: PyPI and OpenPGP keys (was: RFC: advise against using Proton Mail for Debian work?)

[Jeremy Stanley]

On 2023-11-17 01:55:45 +0100 (+0100), Salvo Tomaselli wrote:
> You have a system that is an insane overkill. I'm one guy with one
> computer and no funding to do any of this.

I admitted as much. My point was that building, signing, and
uploading the tarball to PyPI are distinct steps which can be
performed separately in different places. You were arguing that if
you wanted to use GitHub Actions to authenticate your uploads to
PyPI then that necessitated putting your private OpenPGP key there
too, and I was trying to demonstrate that your assertion is patently
false. Build/sign in one place, upload from another (like GitHub
Actions in this case). That totally works. It also seems like common
sense, so I get the feeling I'm not understanding your actual
complaint.

> The maintainer of pypi stated that the issue of the global token
> being needed is fixed. But it is fixed IIF you upload via github's
> CI.
> 
> But I want to sign things and I want the pypi thing to be
> identical to the one that I sign.

Build and sign it, then hand what you built off to your uploading
system. Why wouldn't it be the same? PyPI also reports a strong
checksum for each uploaded file, so if you don't want to download it
again to double-check, you could just compare that to the checksum
of the local file that you signed.

> So some other user suggested that I should upload an easy to
> revoke key and use that one to sign.

If you're talking about the discussion on the Python Discourse, I
think that was me. I remember pointing out that some people who *do*
choose to perform OpenPGP signing of artifacts in build automation
like CI/CD systems do so with a signing subkey in order to not give
their primary private key to that automated system. This really has
nothing to do with how you upload files to PyPI though, so I
continue not to understand what your actual complaint is.

> In the end pypi's security got worse because I used to type in my
> password to upload, while now I am forced to keep it in a plain
> text .txt file for twine to be able to read it.

You should be able to interactively enter the upload token too, it's
really just a password with a common username ("__token__"). You
have to prefix the token string with "pypi-" though when entering it
like a password. See the PyPI help page for details:

https://pypi.org/help/#apitoken

I haven't tested doing that with Twine specifically, but it ought to
just work.

> This is because one of my project is "essential" or whatever. So I
> must use the 2 factor authentication, which is actually needed
> only once, to create a global token and then can be ignored
> forever.

I do disagree with how they forced 2FA on a subset of maintainers
based on some arbitrary metric, and then tied required use of
separate upload tokens to that, but since I don't help to run the
service it's ultimately not my call.

> I personally actually revoke the global token every time, and
> create a new per-project one. But I can guarantee you that 99% of
> people in my situation are using a global token for everything.
> 
> So in the effort to improve security pypi dropped signatures, and
> forces people to keep the password in a .txt file.

As I mentioned above, you're not required to store the token in a
file unless you want to be able to use it non-interactively. But I
agree, most people probably are just sticking it in a file. To be
fair though, most people did that with the old username/password
system for PyPI uploads too, I expect.

> Personally I think security was not improved, and seems that the
> maintainers of pypi don't even realise. But that's my perception.

It's a step up from when non-interactive use required you to put
your PyPI account password in a file. At least upload tokens only
have the ability to upload new versions of your projects, they're
scoped to disallow anything else. Having 2FA to log into the account
in order to get access to the other functions is arguably a little
more secure than before too.

But yes, they have made things more complicated and more
inconvenient, which often ends up pressuring users into finding
less-secure workarounds, defeating the purpose of the additional
measures they enacted.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: RFC: advise against using Proton Mail for Debian work?

[Jonathan McDowell]

On Wed, Nov 15, 2023 at 11:21:06PM +0100, Norwid Behrnd wrote:
> I would like to add an observation tangential to your points A), explanation
> to new contributors, and B) potentially advise against the use of Proton Mail
> for Debian work to yield a «no, Proton Mail can be useful for some Debian
> work».

I'll chip in, without wearing any hats, to comment that:

a) I completely agree with all the sentiments raised about not storing
the private portion of OpenPGP keys on other people's systems; this
extends to systems run by DSA (in the distant past we had to do a clean
up of DD keys that had been stored on master).

but

b) Proton Mail are active members of the OpenPGP ecosystem and are doing
good work in trying to improve it's usefulness and usability. I have no
reason to object to their use within Debian, as long as upload keys are
not stored there.

J.

-- 
/-\ |   "Do I scare you?" "No." "Do you
|@/  Debian GNU/Linux Developer |   want me to?" -- Wayne's World.
\-  |


signature.asc
Description: PGP signature

Debian package signing and integrity (was: RFC: advise against using Proton Mail for Debian work?)

[G. Branden Robinson]

At 2023-11-15T14:58:15+, Jeremy Stanley wrote:
> I replied to you there too, but you still never seemed to be able to
> explain... why do you need to put an OpenPGP key on the service
> you're using to upload Python packages (not Debian packages) to
> PyPI, given that PyPI doesn't support uploading OpenPGP signatures
> anyway?

Yeah, this seems really scary to me.  The private key of a
public/private key pair associated with an identifiable individual
should absolutely be under the _exclusive_ control of that individual.
Including read access.

I thought this idea was, like, practical crypto 101.

Am I missing something?

> Yes I'm also annoyed that they saw no value in software authors
> uploading signatures for their release artifacts, I argued
> repeatedly in favor of keeping it, but the PyPI maintainers (rightly
> or wrongly) saw it as a mostly-unused attractive nuisance, and
> assert that their more recent addition of HTTPS and strong checksums
> mostly serves the purpose of users being able to double-check that
> what they downloaded is what PyPI meant to serve them (even if they
> can't as easily double-check that what they downloaded is what the
> author believes was originally uploaded).

It's funny how the same arguments recur over time.  Back in 2001, Ben
Collins, John Goerzen, and Wichert Akkerman tried to get this same sort
of thing into practice into Debian, and faced a wall of indifference
from the archive administration team[1].  One may recognize this
approach to package signing as a Merkle tree, an old concept even at the
time that was popularized as a thoroughly innovative lightning stroke of
genius called "blockchain" several years later.

(I seem to remember that John and I worked on a brief USENIX-style white
paper describing this, but I've long since lost track of it.  I also
don't remember if we tried to submit it for DebConf 1 or 2.[8])

I was excited by this development at the time, because it provided a
user-verifiable chain of custody for source bits.  You could have nested
signatures by the (source) package uploader, the party who built the
binary package, and one by each/any archive host.

I recall from IRC that some of the resistance was due to a vague notion
that package signing was suspect because John and I were drawing
salaries from Ian Murdock's company, Progeny Linux Systems; that some
hidden agenda was therefore at work[2], producing an undisclosed
conflict of interest.  Some of these same people suddenly perceived
massive _synergies_ of interest when they themselves started drawing
salaries from Mark Shuttleworth's Canonical Software.  All of a sudden,
they couldn't endorse external agendas enough.  Go figure.

It's noteworthy to me that, despite much more widespread understanding
of Merkle trees nowadays[3], one's opinion of the value of nested,
signed checksums seems to have a strong negative correlation with one's
status as an administrator of a centralized repository, such that only
the last link in the chain of custody is considered important.  With
that threat model, there's no need to compromise any packager's or
uploader's key; you conduct an injection attack on the archive directly.

And _that's_ something that's never happened to anyone, right?[7]

Regards,
Branden

[1] a.k.a. "ftpmasters", a term I have always refused to use because it
is too depressingly Nietzchean--if there's anything that team wasn't
lacking back them, it as a Will to Power...

https://lists.debian.org/debian-dpkg/2001/03/msg00024.html

[2] Such a fear isn't crazy.  Plenty of startups predicate their
promises of future profitability on some sort of "secret sauce" or
process of market capture.  But there would not have been any way to
convince anyone of that at the time.  As the saying goes, "you can't
reason someone out of a belief they weren't reasoned into".  As it
happened, (A) John and I would have been opposed to any such
unethical leveraging effort had one been on offer;[4] (B) Ben and
Wichert weren't affiliated with or compensated by Progeny in any
way;[5] (C) the design and implementation of the initiative were
completely transparent, and their applicability to the problem of an
indeterminate chain of (bit-modifying) custody obvious; and (D)
while it was pursuing a business plan of "get acquired for an absurd
amount of money", the company's strategic direction whipped to and
fro like an unmoored fire hose, depending on whatever Ian was
reading (or who he was talking to) at the time...I suspect that
these were frequently investors who knew far less about the industry
than he did.  Culturally, it doesn't seem that we've gotten any
better distinguish wealth (or the illusion thereof[6]) from domain
knowledge, competence, or virtuous character.

[3] Well, maybe not.  For one rollicking, schadenfreude-inducing tale of
vapidity, cupidity, and stupidity after another, see

Re: RFC: advise against using Proton Mail for Debian work?

[Russ Allbery]

Jeremy Stanley  writes:

> Or build and sign the .tar.gz, then provide the .tar.gz file to the
> upload automation on GitHub for publishing to PyPI.

Oh, yes, that would work.  You'd want to unpack that tarball and re-run
the tests and whatnot, but all very doable.

-- 
Russ Allbery (r...@debian.org)  

Re: RFC: advise against using Proton Mail for Debian work?

[Jeremy Stanley]

On 2023-11-15 16:03:54 -0800 (-0800), Russ Allbery wrote:
[...]
> Well, you *can*, but you would have to then download the .tar.gz from
> PyPI, perform whatever checks you need to in order to ensure it is a
> faithful copy of the source release, and then sign it and put that .asc
> file somewhere (such as a GitHub release artifact).
[...]

Or build and sign the .tar.gz, then provide the .tar.gz file to the
upload automation on GitHub for publishing to PyPI.

Anyway, the related discussion topic on the Python Discourse forum
is already brainstorming alternative token permissions to make it so
that you can pre-create the per-project upload tokens for projects
before they actually exist, or perhaps make yet another token type
that can only upload an initial release and gets refused if the
project already exists on PyPI, so for people who don't want to or
can't use the "trusted publisher" authentication mechanism (which
only supports GitHub Actions for now), there will likely be more
options in the future that also avoid use of global API tokens.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: RFC: advise against using Proton Mail for Debian work?

[Russ Allbery]

Salvo Tomaselli  writes:

> I am currently not using any service to upload to pypi. But this
> requires the occasional creation and deletion of global tokens.

> The only way to avoid global tokens is to upload from github, in which
> case I can no longer sign the .tar.gz.

Well, you *can*, but you would have to then download the .tar.gz from
PyPI, perform whatever checks you need to in order to ensure it is a
faithful copy of the source release, and then sign it and put that .asc
file somewhere (such as a GitHub release artifact).

But it's an annoying process and I'm not sure anyone has automated it.

> A signature isn't the same as a checksum. Probably nobody was using them
> because there was no way to check them automatically.

I suspect this chicken-and-egg problem is the heard of it.  There are
similar mechanisms for Perl modules that, last I checked, no one really
used, although I think there was some recent movement towards maybe
integrating it a bit more.  It's very hard to create a critical mass of
people who care enough to keep all the pieces working.

PGP signatures definitely seem to be a minority interest among most
upstream language communities.

-- 
Russ Allbery (r...@debian.org)  

Re: PyPI and OpenPGP keys (was: RFC: advise against using Proton Mail for Debian work?)

[Jeremy Stanley]

On 2023-11-16 00:20:40 +0100 (+0100), Salvo Tomaselli wrote:
> In data mercoledì 15 novembre 2023 15:58:15 CET, Jeremy Stanley ha scritto:
> > why do you need to put an OpenPGP key on the service
> > you're using to upload Python packages (not Debian packages) to
> > PyPI, given that PyPI doesn't support uploading OpenPGP signatures
> > anyway?
> 
> I need to create a .tar.gz and a .tar.gz.asc.
> 
> I am currently not using any service to upload to pypi. But this
> requires the occasional creation and deletion of global tokens.
> 
> The only way to avoid global tokens is to upload from github, in
> which case I can no longer sign the .tar.gz.
[...]

I guess what I'm still not understanding is why your upload to PyPI
has to happen from the same system where the artifact was built (and
possibly also where it was signed). The system with your OpenPGP
signing key and build toolchain doesn't have to be the same system
as where your PyPI upload credentials reside.

I manage a very much non-GitHub CI/CD infrastructure that builds
artifacts on one system, securely retrieves them from there and
signs them on another system, then uploads them to PyPI from yet
another system. The build toolchain has no direct access to the
OpenPGP signing key, nor does the PyPI uploading tool. The build
toolchain also has no access to the PyPI upload credentials, all of
these different steps are isolated from one another by the CI/CD
system.

A solution like that is almost certainly overkill for casual
efforts, our community has hundreds of projects with thousands of
releases managed through central automation making it more
worthwhile, but the point is that none of those steps needs to
happen on the same system. This is why I continue not to understand
how you think using PyPI's "trusted publisher" would necessitate
giving your (entirely unrelated to that process) OpenPGP private key
to GitHub, or to whatever future systems PyPI adds a trust
relationship with for that matter for that matter.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: RFC: advise against using Proton Mail for Debian work?

[Steve McIntyre]

I wrote:
>nil...@mailbox.org wrote:
>>
>>>2. The Proton Mail web client automatically encrypts email to anyone who
>>>it has a key for.  Usually, this would be a great thing, but it means
>>>that emailing 1234 at bugs.debian.org while CCing
>>>uploader_since_this_is_an_rc_...@debian.org will encrypt the email that
>>>is sent to the BTSe...which has the effect of making Debian development
>>>veiled in plain sight rather than "in the open".
>>
>>Does it not encrypt email per-sender?
>
>Ewww, I certainly hope so!

So I've just set up a ProtonMail test account to verify. Mailing to
myself, it already clearly knew about my PGP key (I've already had
lots of encrypted mails from ProtonMail users), but sending to a
different address that came through in plain text.

So *that* doesn't seem to be a worry, but the concern about people
sharing private keys is still very real... :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Re: RFC: advise against using Proton Mail for Debian work?

[Norwid Behrnd]

Hello,

I would like to add an observation tangential to your points A), explanation
to new contributors, and B) potentially advise against the use of Proton Mail
for Debian work to yield a «no, Proton Mail can be useful for some Debian
work».

In December 2022/January 2023, I found a sponsor for my first contribution
`ruby-mdl`/`markdownlint` (a syntax checker[1]) via mentors.debian.net.  In
preparation of an upgrade in October 2023, the earlier workflow did not work
any more because messages as for instance «your upload was accepted to mentors»
did not reach me.  The credit is due to Baptiste Beauplat to figure out yahoo
no longer accepts the emails by mentors.debian.net which are sent by a
hostname.[2]  It was (I speculate: possibly still is) uncertain if/when yahoo
is going to adjust its policy in favor of Debian.

Meanwhile, the free protonmail account provided a bypass to submit again
updates of my package to mentors.debian.net .and. to receive again the
notifications from this site.  For this, I created locally a new GPG key pair
about the protonmail address of which the public key was uploaded to
salsa.debian.net and mentors.debian.net.  This local key pair equally is the
one currently used for `debsign` on the .changes file prior to `dput mentors
...changes` to eventually file a RFS on mentors.

The local GPG key pair is a different one of the one provided by protonmail,
the two already discernible by their different fingerprints.  In terms of
technology, protonmail's key lists as key type `ECC (Curve25519)` while the
options in the Kleopatra GUI[3] offer RSA, DSA, and type ECDSA/EdDSA, too.

So in short: for this less than DM-level contribution to Debian, protonmail
can be useful.

Norwid

P.S.: In the longer run, the absence of IMAP/SMTP, the constraint of three
folders to organize emails in a hierarchic approach (or three tags to label the
messages irrespective a hierarchy) in the free version are incentives to
opt-in in pm's subscription based use.

[1] https://tracker.debian.org/pkg/ruby-mdl
[2] https://wordtothewise.com/2023/05/unresolvable-rfc-5321-domain-at-yahoo/
[3] https://tracker.debian.org/pkg/kleopatra

Re: RFC: advise against using Proton Mail for Debian work?

[James Addison]

Hi,

My few smallcoins, responding to each of the proposed outcomes (even
if they were intended to be mutually-exclusive...) are:

A) Educating contributors that retaining control of their signing keys
is important seems valuable -- it seems OK to provide a few
illustrative examples of situations where relinquishing or losing
control of keys could be problematic, and the reasons why.

B) To follow the security vulnerability disclosure model: it seems OK
to indicate that a given vendor is problematic for a specific,
communicable reason -- and beneficial to contact them first to
indicate the concern and ask whether they're aware of a problem and to
check whether they're willing-and/or-able to mitigate that.

C) If the risk is vendor capture of key material, then a similar
concern should probably be about vendors who provide functionality
that could lock contributors into their ecosystem for any reason.  In
other words: if the concern is about behavioural coercion or that an
entity may behave in future in ways that a key author might not
intend, then I'd argue that it's not only the author's key material,
but also the output communication styles and abilities allowed by the
vendor that should be questioned.  So: it's fine for a vendor to do
something to help Debian, but it should be in a way that any other
vendor can implement, based on a public, ideally DFSG-compliant,
specification.

Regards,
James

Re: RFC: advise against using Proton Mail for Debian work?

[Jeremy Stanley]

On 2023-11-15 11:01:35 +0100 (+0100), Salvo Tomaselli wrote:
[...]
> I was recently discussing with pypi and core python developers,
> and it seems that their take is very different than ours.
> 
> It seems that pypi completely removed support for signed updates,
> and instead now verification happens if you upload from a github
> pipeline.
> 
> It has been suggested that I'm a bit paranoid for stating that
> putting my private key on a microsoft server renders the signature
> with that key completely meaningless.
> 
> I of course disagree, but the opinion of people in such key
> positions is easily valued more.
> 
> Perhaps we need an explicit policy in how to handle keys, since
> there are very different opinions about what it is ok to do with
> them.

I replied to you there too, but you still never seemed to be able to
explain... why do you need to put an OpenPGP key on the service
you're using to upload Python packages (not Debian packages) to
PyPI, given that PyPI doesn't support uploading OpenPGP signatures
anyway?

If you're equating PyPI's "trusted publishers" feature with signing
packages, you've misunderstood the intent. It's a way of delegating
upload authentication to public identity providers in order to
better secure upload automation in CI systems (in lieu of giving
them a fixed username+password or long-lived API token):

https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/

If you're going to be concerned about something with that particular
feature, I think it should probably be that they've so far only
implemented support for GitHub Actions; though it sounds like
they're willing to entertain other authentication providers if
someone is interested enough to write the necessary drivers/config
for them. But to reiterate, PyPI's old "you can upload detached
signatures" feature was never used to authenticate anything, it
served an entirely different purpose. The "trusted publishers"
feature really has no similarity with it whatsoever.

Yes I'm also annoyed that they saw no value in software authors
uploading signatures for their release artifacts, I argued
repeatedly in favor of keeping it, but the PyPI maintainers (rightly
or wrongly) saw it as a mostly-unused attractive nuisance, and
assert that their more recent addition of HTTPS and strong checksums
mostly serves the purpose of users being able to double-check that
what they downloaded is what PyPI meant to serve them (even if they
can't as easily double-check that what they downloaded is what the
author believes was originally uploaded).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: RFC: advise against using Proton Mail for Debian work?

[Hakan Bayındır]

Hello,

I completely agree with you and many others on that regard. A private 
key is private, and shall not be stored in a server where multiple users 
might access to and open to internet, which can be compromised.


Doing this makes the attack surface substantially larger, and given the 
target is important enough, makes the server target of more 
sophisticated attacks which might be harder to detect.


> It has been suggested that I'm a bit paranoid for stating that putting my
> private key on a microsoft server renders the signature with that key
> completely meaningless.

Given that Microsoft lost their private keys allowing anyone to sign 
login tokens, stayed silent for so long on the matter, not giving 
private keys to Microsoft is a wise choice.


As a result, a general policy change disallowing private keys to be 
stored in these remote systems is a welcome addition from my PoV.


Cheers,

H.

On 15.11.2023 13:01, Salvo Tomaselli wrote:

Hello,


In data mercoledì 15 novembre 2023 03:21:34 CET, Simon Richter ha scritto:

disqualifying factor. Upload permissions are tied to a gpg key, and the
holder of the key needs to at least demonstrate good practices in using
gpg


I was recently discussing with pypi and core python developers, and it seems
that their take is very different than ours.

It seems that pypi completely removed support for signed updates, and instead
now verification happens if you upload from a github pipeline.

It has been suggested that I'm a bit paranoid for stating that putting my
private key on a microsoft server renders the signature with that key
completely meaningless.

I of course disagree, but the opinion of people in such key positions is
easily valued more.

Perhaps we need an explicit policy in how to handle keys, since there are very
different opinions about what it is ok to do with them.


Best




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: RFC: advise against using Proton Mail for Debian work?

[Steve McIntyre]

nil...@mailbox.org wrote:
>
>>2. The Proton Mail web client automatically encrypts email to anyone who
>>it has a key for.  Usually, this would be a great thing, but it means
>>that emailing 1234 at bugs.debian.org while CCing
>>uploader_since_this_is_an_rc_...@debian.org will encrypt the email that
>>is sent to the BTSe...which has the effect of making Debian development
>>veiled in plain sight rather than "in the open".
>
>Does it not encrypt email per-sender?

Ewww, I certainly hope so!

Do we have any examples of encrypted mails hitting the BTS?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Re: RFC: advise against using Proton Mail for Debian work?

[Luci Stanescu]

Hi,

I'm new to this mailing list, having joined hoping to contribute to Debian, so 
I hope you won't mind me offering my opinion here, with this being a subject 
I'm quite keen on.

> On 15 Nov 2023, at 12:01, Salvo Tomaselli  wrote:
> 
> In data mercoledì 15 novembre 2023 03:21:34 CET, Simon Richter ha scritto:
>> disqualifying factor. Upload permissions are tied to a gpg key, and the
>> holder of the key needs to at least demonstrate good practices in using
>> gpg
> 
> I was recently discussing with pypi and core python developers, and it seems 
> that their take is very different than ours.
> 
> [...]
> 
> Perhaps we need an explicit policy in how to handle keys, since there are 
> very 
> different opinions about what it is ok to do with them.

PGP/GPG signatures used in this way offer an origin-of-data proof and 
non-repudiation tied to whoever controls the private key – there are no grey 
areas. If a private key is stored on an end-user's device, that means anyone 
who has access to said device OR can compromise said device. If a device is 
backed up, this of course extends to whoever can access or compromise said 
backup. And if the private key is processed by a service such as Proton Mail, 
then the origin-of-data proof and non-repudiation properties extend to whoever 
has access to Proton Mail systems or whoever can compromise it. The value of a 
digital signature will weaken as this list gets longer.

This is, of course, not to say that the Proton Mail people are in any way 
ill-intentioned or that their service can be easily compromised. My point is 
that it is the responsibility of whoever accepts a digital signature as an 
origin-of-data proof to understand its value and the associated risks. The 
risks are unlikely to be nil, but can be accepted or reduced; they should never 
be ignored, though. That means you *can* accept the fact that a disgruntled 
Proton Mail employee or someone who compromises them could generate signatures, 
you just shouldn't ignore that fact.

There are many more related issues here, such as the fact that even though a 
private key is normally encrypted at rest (which usually covers its 
confidentiality aspect for backups), encryption should never be considered 
perfect or valid in perpetuity – limits for how long encryption is considered 
to offer confidentially are generally established based on algorithm and key 
length (usually on the order of a few years) and this, in turn, dictates the 
need to generate new private keys in the PGP/GPG case (since loss of 
confidentiality of a private key implies loss of the origin-of-data proof and 
non-repudiation for its signatures).

My opinion is that it is an excellent idea to have a policy for handling keys – 
this is very much an industry-recommended practice. To get an idea, SANS has a 
bunch of information security templates to get people started and this includes 
a Digital Signature Acceptance Policy [1]; this may be a bit basic for Debian's 
needs or targeted at other kinds of organisations, but I've mentioned this just 
so you can get an idea.

I really think this is a great discussion to have, because software supply 
chains are only now becoming something people begin to talk about (and that's 
really because they're being increasingly targeted by malicious entities).

Thank you for your time reading this!

[1] https://www.sans.org/information-security-policy/?page=2

-- 
Luci Stanescu
Information Security Consultant

Re: RFC: advise against using Proton Mail for Debian work?

[Stephan Lachnit]

While I do think that PM generating a PGP key by default is a good
thing. Even if they are compromised, it is still better than no
encryption for the vast majority of user *as long as they are not used
for something else*.

The problem for us is that it is not possible to upload subkeys to PM,
which allow to DM/DDs to create a subkey just for PM use. But even
then I'm not aware on how to push a public key without that subkey to
the Debian keyring, so maybe it doesn't matter.

In any case, I don't think condemning the use of PM is justified here.
Their software is open source and they are one of the only email
provider that actually care about encryption. Yes, it doesn't work
well with the Debian workflow, but that is not really their (nor our)
fault. The percentage of people that just use mail on PM is probably
significantly larger than those that also use their PGP mail to
sign/encrypt other stuff like Debian packages.

Cheers,
Stephan

Re: RFC: advise against using Proton Mail for Debian work?

[Pierre-Elliott Bécue]

Nilesh Patra  wrote on 15/11/2023 at 03:49:12+0100:
> On 15 November 2023 5:10:50 am IST, Nicholas D Steeves  
> wrote:
>>On the surface, this means Proton Mail (free account) is great!  And for
>>general use, I feel like we should be supportive of them; however, I'm
>>starting to wonder if we need to recommend against the use of Proton
>>mail for Debian work for the following two reasons:
>>
>>1. I've received a report that this provider is not appropriate for DM
>>and DD use, because the key pair is stored on their servers.  Ie: The
>>applicant doesn't control the means to validating identity and
>>authorship.
>
> 100% agreed.
>
> I once advocated a DM who uses protonmail and a few months (after they
> became a DM), I came to know about PM's storing keys in the server.
> So I quickly checked with the person in question if they pushed their
> keys to PM's servers, and to my utter horror, they did.
>
> I quickly made the keyring maint know and their keys were removed
> immediately and a new pair of keys were later added back after a few
> months when enough trust was established for those.
>
> This is not the only instance I faced this. Another individual whom I
> advocated for being a DM also did this, but we found out about it
> before the process started.
>
> People who are new to the GPG thing end up thinking it's okay to add
> their keys to PM - which is fine, but this is as good as compromised
> from the debian view which I think is correct.
>
> Due to this, I'm always skeptical whenever I receive a PGP signed or
> encrypted email from protonmail.

Following this specific event, the discussions we had between
FD/DAM/Keyring Maint seemed clear: a GPG key for which the private
component can't be trusted to be owned/managed/accessible only by the
DD/DM to whom it's supposed to belong can't stay in the keyring as it
can't be trusted.

-- 
PEB


signature.asc
Description: PGP signature

Re: RFC: advise against using Proton Mail for Debian work?

[Nilesh Patra]

On 15 November 2023 5:10:50 am IST, Nicholas D Steeves  wrote:
>On the surface, this means Proton Mail (free account) is great!  And for
>general use, I feel like we should be supportive of them; however, I'm
>starting to wonder if we need to recommend against the use of Proton
>mail for Debian work for the following two reasons:
>
>1. I've received a report that this provider is not appropriate for DM
>and DD use, because the key pair is stored on their servers.  Ie: The
>applicant doesn't control the means to validating identity and
>authorship.

100% agreed.

I once advocated a DM who uses protonmail and a few months (after they became a 
DM), I came to know about PM's storing keys in the server.
So I quickly checked with the person in question if they pushed their keys to 
PM's servers, and to my utter horror, they did.

I quickly made the keyring maint know and their keys were removed immediately 
and a new pair of keys were later added back after a few months when enough 
trust was established for those.

This is not the only instance I faced this. Another individual whom I advocated 
for being a DM also did this, but we found out about it before the process 
started.

People who are new to the GPG thing end up thinking it's okay to add their keys 
to PM - which is fine, but this is as good as compromised from the debian view 
which I think is correct.

Due to this, I'm always skeptical whenever I receive a PGP signed or encrypted 
email from protonmail.

>2. The Proton Mail web client automatically encrypts email to anyone who
>it has a key for.  Usually, this would be a great thing, but it means
>that emailing 1234 at bugs.debian.org while CCing
>uploader_since_this_is_an_rc_...@debian.org will encrypt the email that
>is sent to the BTSe...which has the effect of making Debian development
>veiled in plain sight rather than "in the open".

Does it not encrypt email per-sender?

>I see three outcomes:
>
>A) Continue to explain this to new contributors on a one-by-one basis.
>B) Advise against using Proton Mail for Debian work (where?  our wiki?)

It might be good to give a warning about pushing PGP keys to proton mail's 
servers and it's implication on debian work *and* also inform new contributors 
on one by one basis who may not have seen the wiki.

I also think that providers that do not offer IMAP/POP3 are not very 
recommended for debian work too as you lose the ability to use a mailing client 
(and sign your mails). I think it'd be good to add a note about that as well. 
I've seen at least 2 people start with a tutanota email address and later 
switch due to this reason.

>C) Proton Mail begins to do something differently on their end, such as
>offering some features to Debian contributors that currently require a
>subscription.

This does not look feasible since 'Debian contributors' is a broad term and 
it'd be impractical to classify people there and give them access.
What could _maybe_ make sense is to have case-by-case endorsements for debian 
contributors to get such features.

>P.S. Also, at what point should we add them to CC and/or write them an
>open letter?

I think whenever we reach a sensible way forward :)

If they don't already, probably adding a warning regarding PGP keys in their 
webUI could be good as well.

Best,
Nilesh

Re: RFC: advise against using Proton Mail for Debian work?

[M. Zhou]

On Tue, 2023-11-14 at 18:40 -0500, Nicholas D Steeves wrote:
> 
> I see three outcomes:
> 
> A) Continue to explain this to new contributors on a one-by-one
> basis.
> B) Advise against using Proton Mail for Debian work (where?  our
> wiki?)
> C) Proton Mail begins to do something differently on their end, such
> as
> offering some features to Debian contributors that currently require
> a
> subscription.

Instead, is it possible to make BTS reject encrypted (unreadable)
mails? In that way no particular service name has to be mentioned
and Debian members will be able to figure out the mail service
has got an issue.

Discouraging the usage of a certain service publically just
because of some technical issues (instead of ethical/moral/legal)
is very much likely problematic, as an organization.
Plus, the 5-th clause if DFSG is "no discrimination against
persons or groups". People outside the community will mock us
if we ban it like this.

I just felt some sort of resemblance to "XXX operating system
is evil, do not use it". Whether or not people agrees with it
personally, it is inappropriate to make such opinion official.

Re: RFC: advise against using Proton Mail for Debian work?

[Simon Richter]

Hi,

On 11/15/23 08:40, Nicholas D Steeves wrote:


1. I've received a report that this provider is not appropriate for DM
and DD use, because the key pair is stored on their servers.  Ie: The
applicant doesn't control the means to validating identity and
authorship.


Correct. I'd even go as far and say that using it should be a 
disqualifying factor. Upload permissions are tied to a gpg key, and the 
holder of the key needs to at least demonstrate good practices in using 
gpg, ideally also have enough understanding to be able to derive good 
practices and not just follow a set of rules.


The gpg signature is not just a formal requirement where it doesn't 
matter how it is generated, but an integral part of the trust chain.



A) Continue to explain this to new contributors on a one-by-one basis.


I think that is part of Tasks


C) Proton Mail begins to do something differently on their end, such as
offering some features to Debian contributors that currently require a
subscription.


Unless that feature is "you control your own secrets", that makes no 
difference, it remains unsuitable and anyone using it in this manner 
demonstrates that they are not yet ready for the responsibilities of 
Debian membership.


And "control your own secrets" as a perk of paid membership would be an 
even bigger level of wrong.


   Simon

RFC: advise against using Proton Mail for Debian work?

[Nicholas D Steeves]

Hello,

Please retain me in CC for all replies.

Everyone reading this most likely believes that PGP/GPG is a good thing;
Many will advocate for its use-by-default for even unimportant
correspondences, because privacy is a right.  Meanwhile, everyday usage
of encryption normalises it, which is important because the means to
privacy should not a niche crypto enthusiast thing...

On the surface, this means Proton Mail (free account) is great!  And for
general use, I feel like we should be supportive of them; however, I'm
starting to wonder if we need to recommend against the use of Proton
mail for Debian work for the following two reasons:

1. I've received a report that this provider is not appropriate for DM
and DD use, because the key pair is stored on their servers.  Ie: The
applicant doesn't control the means to validating identity and
authorship.

2. The Proton Mail web client automatically encrypts email to anyone who
it has a key for.  Usually, this would be a great thing, but it means
that emailing 1234 at bugs.debian.org while CCing
uploader_since_this_is_an_rc_...@debian.org will encrypt the email that
is sent to the BTSe...which has the effect of making Debian development
veiled in plain sight rather than "in the open".

I see three outcomes:

A) Continue to explain this to new contributors on a one-by-one basis.
B) Advise against using Proton Mail for Debian work (where?  our wiki?)
C) Proton Mail begins to do something differently on their end, such as
offering some features to Debian contributors that currently require a
subscription.

What do you think?
Nicholas

P.S. Also, at what point should we add them to CC and/or write them an
open letter?


signature.asc
Description: PGP signature