At 2023-11-15T14:58:15+0000, 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
    <https://davidgerard.co.uk/blockchain/book/>.

[4] Years later, I learned that my ethical principles almost got me
    fired.  Story for another time...

[5] To my knowledge.  The company didn't open its books to its staff
    until much, much later, under different leadership, and when the
    place was in desperate straits.  It was and remains a radical move,
    a fact I've always found fascinating.  Capitalists bray and bleat
    about the infallible wisdom of the market, when a necessary
    precondition of a market's ability of find an optimal equilibrium
    between supply and demand is predicated, among several other
    factors, on perfect information.  (Don't take my word for it; read
    Kenneth Arrow and Gérard Debreu.)  In practice, they love secrets as
    much as--or more than--Joseph Stalin and Lavrentiy Beria did.  There
    is also the massively distorting effect of "limited liability", but
    I digress.

[6] 
https://www.reuters.com/legal/ftx-founder-sam-bankman-fried-thought-rules-did-not-apply-him-prosecutor-says-2023-11-02/

[7] 
https://www.bleepingcomputer.com/news/security/hundreds-of-malicious-python-packages-found-stealing-sensitive-data
 /
    
https://arstechnica.com/information-technology/2022/08/10-malicious-python-packages-exposed-in-latest-repository-attack/
    
https://arstechnica.com/information-technology/2020/04/725-bitcoin-stealing-apps-snuck-into-ruby-repository/
    
https://arstechnica.com/information-technology/2021/12/malicious-packages-sneaked-into-npm-repository-stole-discord-tokens/

[8] I suspect we didn't.  DebConf 1 was way over in Europe and Progeny
    wasn't going to spend the money to send anyone but Ian overseas at
    that point.  DebConf 2 was at York University in Toronto and Progeny
    _did_ send a generous delegation.  But John might have left the
    company by then, and I remember that, faced with the archive admins'
    enduring opposition, we all pretty much gave up trying to advance
    the state of the art in that direction.

Attachment: signature.asc
Description: PGP signature

Reply via email to