Roadmap update for TUF support #5247
Comments
|
Thanks - good question. |
|
I believe that the package signing issues stated can be resolved and in 2019 our internet depends on the security of infrastructure such as PyPI. If there is not a roadmap for TUF support, I'm going to look at solving the problem. |
|
Perhaps we can evaluate integration with third-party services for verification? Now, this does assume putting trust in third-party services themselves (and the author of the actual PGP key), but the chances are very slim that your PGP key would be replaced on multiple services at once. The biggest issue is an author being unable to secure their private key (no password, weak password, bad private key handling, etc...), or their account becoming compromised (e.g. GitHub). This doesn't solve the problem on PyPi's side of verifying someone, although PyPi shouldn't have to verify anyone. PyPi should host the package. It should display information about the package being signed (or unsigned), the package's origins and contents, and whoever is downloading the package should check that key against their trusted sources. I'm sure we all can go on about this. If a user or a maintainer doesn't care about signing, it doesn't have to be enforced at the beginning, If the feature is there, people will use it. Edit: |
|
I am convinced that this problem is tractable and I think the key here is that EigenTrust can provide us a mathematical model to get started. We already have some data in the git commit history. When someone signs a git commit there is an eigentrust metric that can be calculated for all of the previous signed commits. There is reason to believe that causality and techniques like Bayesian inference may also be useful here where multiple commits are signed by a key we do not yet trust, but are temporally followed by a key we do trust. We can also federate our memories of git history and checksums to detect anomalies and attacks on infrastructure. Sites like github and sr.ht can already provide trust metrics by validating that an email address is connected to a GPG key. We can formalize and automate our existing manual heuristics for validating packages. Further I think we should start thinking about metadata for developers and organizations that produce software. Organizations can maintain a META-DEV repository that contains the PGP signing keys of active developers, key revocation information, and per repository release manager designation. Developers can also maintain a META-DEV repository that contains yaml (or whatever) metadata linking to a developers twitter / blog / instagram / keybase / identi.ca / matrix / Mastodon / xmpp / whatever where the PGP fingerprint can be posted. Perhaps we need to start building keyrings in OS native packaging formats (.deb, .rpm, etc) so that trust can at least be established for the most critical python packages. This is a complex problem but we need to take what small steps forward that we can instead of waiting another year to secure PyPI or even bother to figure out certificate pinning. |
brainwane
added
the
needs discussion
|
Thank you to everyone who's raised this issue and shared their thoughts and useful resources! And sorry for the slow response! Short answer: we'll be discussing TUF & Warehouse much more in April. Longer answer: The folks working on Warehouse have gotten funding to concentrate on improving Warehouse's security, and have kicked off work (funded by the Open Technology Fund) towards multi-factor auth, API keys, and an audit trail. And -- to quote the blog post --
We anticipate that in mid-April (so, basically within about a month) we'll be announcing a formal Request For Information to ask people to tell us about their interest in being contracted to do this work, and that part of that discussion will be further, more detailed conversations about whether TUF is the right tool for this job. So please watch for that, on this issue and on https://discuss.python.org/c/packaging . (cc @pradyunsg since I think you're interested in this.) |
|
From the TUF side, we're very interested in moving this forward. Let us know what we can do to help! |
|
Same, happy to help with this, just let us know how. |
|
"PyPI security work: multifactor auth progress & help needed" |
|
At PyCon sprints several people spoke about the potential future of TUF in Warehouse and Python packaging, and put notes at https://docs.google.com/document/d/1Wz2-ECkicJgAmQDxMFivWmU2ZunKvPZ2UfQ59zDGj7g/ . |
|
I'll also devote whatever time is necessary to get this done |
|
Thanks for putting together our notes, @brainwane! It was a pleasure meeting you guys at PyCon. @ewdurbin, any news on the RFI? @ofek and @trishankatdatadog, your help will be very much appreciated. |
|
Please check out the newly posted Request for Interest regarding upcoming work implementing cryptographic signing and malware detection on PyPI. Our current timeline:
And then we intend to complete the project over a three to five month period, beginning December 2019. We're hoping to get participation from potential participants and other experts in the discussion forum, especially about implementation questions, including which of the TUF PEPs (if either) to implement! |
|
See the PSF's new blog post & the open RFP. Later this year, PyPI wants to start:
This means we need to move PEP 458 from "Deferred" to "Accepted" status. Per @ewdurbin's guidance, this means we'll need to get PEP 458 revised, as necessary, to pin down specifics, such as key distribution (who, where, how many?) plus any technical choices that TUF leaves up to implementations. To revise PEP 458 and get it accepted, we'll need to collaborate with previous implementers and other experts. Given the RFP timeline the latest we should get the PEP accepted is 2 December 2019, but I'd much prefer we get it accepted by mid-October. |
|
Thanks for the update, @brainwane! @JustinCappos @lukpueh Ok, so we have our work ahead of us. I have work obligations to meet, but can devote whatever time I can for this. Let's plan ASAP. |
|
Let me know if you need more assistance, I'd be glad to help! |
Facebook Research has now funded implementation of cryptographic signing of packages on PyPI. Per pypi/warehouse#5247 (comment) this means that PEP 458 now moves out of Deferred status and into Draft status. Since the PEP was created, the BDFL-Delegate for PyPI-related PEPs has shifted, and Donald Stufft is now the Delegate.
Facebook Research has now funded implementation of cryptographic signing of packages on PyPI. Per pypi/warehouse#5247 (comment) this means that PEP 458 now moves out of Deferred status and into Draft status. Since the PEP was created, the BDFL-Delegate for PyPI-related PEPs has shifted, and Donald Stufft is now the Delegate.
|
Now that the PEP is back in Draft status*, I think the next steps are for one or more of the PEP authors to:
@dstufft is now the BDFL-Delegate for this PEP so it'll have to be the other authors (@trishankatdatadog, @vladimir-v-diaz, @JustinCappos) who push this forward. If we want to get any revisions done and get Donald to accept the PEP by mid-October then you should start the steps above in the next couple days, in my opinion.
|
|
A few of us had a chat today and are working to update the PEP (python/peps#1178 is part of that), and one or more of the PEP authors will be reaching out to @ewdurbin with a few questions. |
|
@brainwane FYI - I'm happy to help with implementing functionality on the client side (i.e. pip) when we get to that point. I think we'd want to create a tracking issue on pip's issue tracker to have implementation related discussions there, after the PEP is accepted (AFAICT how clients interact with TUF-enabled PyPI is covered by the PEP and would be discussed in the discussions on discuss.python.org). |
|
Hi @ewdurbin and @dstufft, we have a few questions for which we could use your help:
Thanks for your time! |
|
Current status: python/peps#1203 is awaiting review from @dstufft to revise PEP 458. After that, there needs to be a discussion on https://discuss.python.org/c/packaging to get the PEP from "Draft" to "Accepted". In order to make implementation easier, Dustin wants to work towards implementing #726 (removing Test PyPI from our infrastructure will make key stuff far easier). @di will be speaking more on that in the relevant issue soon. And, starting in December, @ewdurbin will be managing the contractors who will implement TUF on PyPI. Then the first big key ceremony will be in April at PyCon North America -- if you haven't put PyCon on your calendar yet, you probably should! Conference registration will open later this month. |
|
@jku has some related work people might want to give feedback on, in pip: pypa/pip#8585 and pypa/pip#9041 . |
I believe all of this is still true except that theupdateframework/tuf#1045 is closed. |
|
We addressed all of the blockers for Warehouse integration of TUF mentioned above. The remaining, recently filed, issue in TUF is the addition of an abstract signing interface to support the use of signing keys stored in Hashicorp Vault. That work is being discussed in theupdateframework/python-tuf#1263 |
|
I'm having trouble following some of the twists and turns in the linked issues and pull requests, so please forgive my ignorance -- what is left in order to finalize TUF support on PyPI? Just theupdateframework/python-tuf#574 ? (And then attention ought to move to pypa/pip#8585 to finish up the pip side, I believe.) |
|
On the TUF side, abstract signer support is still needed. secure-systems-lab/securesystemslib#319 added it to SSLib, but I don't believe that work's been integrated into TUF itself yet. Once it is, I'll be able to continue work on the various Vault interfaces that Warehouse will use to sign metadata. |
Correct, though there's a PR which I'm planning to review next week theupdateframework/python-tuf#1272 |
|
It may not be necessary, but is there a milestone or a project board to collect the issues for this epic? "Package signing & detection/verification" says "78%" complete, but milestones can't include issues from other repos? Project boards can reference issues from multiple repos. It's not clear who would create and update a GH project board if even necessary for these issues |
|
I think a project board would certainly help! I only have triage permissions on this repo, so @brainwane or someone else with more permissions might need to either grant me access or do it. |
|
sorry, I don't have time to look into this - @ewdurbin could you see about giving Will project board permissions for this repo? Thanks. |
|
Sorry for joining late at the party. I tried to understand how TUF compares to blockchain protection mechanisms against take over and tampering, and to me TUF claims seem misleading. First TUF main page at https://theupdateframework.io/ claims it provides protection from repo take over.
And then in https://theupdateframework.io/overview/#how-does-tuf-secure-updates it says this.
In the blockhain world that means that attacker can rehash the content of the repo, and trick clients that the signed content is legit, because clients don't even a copy of Merkle Tree hash to validate the repo at any point in history. How TUF is protects from that? Could someone explain it like I am five? If the security (by the spec) is provided by |
|
How this TUF protection is supposed to work? Could someone explain it
like I am five?
@marina Moore ***@***.***> has put together a helpful set of blog posts
( https://ssl.engineering.nyu.edu/blog/ ) that use Santa Claus and
Calvinball (from Calvin and Hobbes) as examples. Let us know if this
helps. :)
|
|
@JustinCappos I am afraid that a distraction for 5 years olds, not an explanation really. :D |
TUF and blockchains are based on different threat models. A blockchain uses decentralized nodes so that an attacker would have to compromise a lot of these nodes to gain control. However, it's not always practical to have a network of trusted nodes for software distribution, and it takes a lot of computation to do the proof-of-work necessary to add new items to a blockchain. TUF instead takes the existing package manager approach, and uses offline keys, revocation, and pinned keys to ensure that a compromise of the repository can be detected and recovered from. Using the blockchain analogy, TUF uses pinned root keys instead of a Merkle Tree hash to validate the state of the repository. This has the advantage that the pinned root keys remain valid through updates to the repository.
This model has already been mostly adopted by PyPI, as well as many others, so it is certainly possible to implement. @trishankatdatadog can provide more insight into deploying TUF in production. I don't know the details about https://fwupd.org/ specifically, but numerous supply chain security compromises of production systems occur because of a repository or key compromise. TUF mitigates these risks through the use of offline keys, threshold delegations, and namespacing. |
|
Also a blockchain doesn't deal with the problems of how do you figure out
what to put on there and who can change it if it is wrong / stale / keys
are compromised. TUF handles those cases.
…On Tue, Aug 31, 2021 at 9:58 PM Marina Moore ***@***.***> wrote:
In the blockhain world that means that attacker can rehash the content of
the repo, and trick clients that the signed content is legit, because
clients don't even a copy of Merkle Tree hash to validate the repo at any
point in history. How TUF is protects from that? Could someone *explain
it like I am five*?
TUF and blockchains are based on different threat models. A blockchain
uses decentralized nodes so that an attacker would have to compromise a lot
of these nodes to gain control. However, it's not always practical to have
a network of trusted nodes for software distribution, and it takes a lot of
computation to do the proof-of-work necessary to add new items to a
blockchain. TUF instead takes the existing package manager approach, and
uses offline keys, revocation, and pinned keys to ensure that a compromise
of the repository can be detected and recovered from. Using the blockchain
analogy, TUF uses pinned root keys instead of a Merkle Tree hash to
validate the state of the repository. This has the advantage that the
pinned root keys remain valid through updates to the repository.
If the security (by the spec) is provided by offline keys and out-of-band
keys distribution, then I don't see how that security can be implemented,
or if it worths the complication. For example, https://fwupd.org/
distributes firmware updates for hardware on Linux, is simple and secure
without TUF. If analogy with the blockchain is hard, this can be used as an
alternative baseline.
This model has already been mostly adopted by PyPI
<https://pyfound.blogspot.com/2020/10/key-generation-and-signing-ceremony-for.html>,
as well as many others <https://theupdateframework.io/adoptions/>, so it
is certainly possible to implement. @trishankatdatadog
<https://github.com/trishankatdatadog> can provide more insight into
deploying TUF in production.
I don't know the details about https://fwupd.org/ specifically, but
numerous supply chain security compromises
<https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises>
of production systems occur because of a repository or key compromise. TUF
mitigates these risks through the use of offline keys, threshold
delegations, and namespacing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5247 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGROD6N5FBEQEUXMELTYMTT7TNXFANCNFSM4GNHO6PQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
I agree. I have no idea why TUF is being compared to a blockchain without the reader doing their due research. If you must, see this article we wrote comparing and contrasting a centralized "blockchain" (transparent/tamper-evident logs) to TUF, and why you probably want to use both. |
|
@mnm678 first, thanks for the explanation. Some nerdy guys like me are completely senseless to people when it comes to "defending the truth". ) I try not to criticize, but when I fail, please forgive me.
That's an mistake no.1 (hope you don't mind the terminology, but I don't know another word). Nodes in blockchain are not trusted. They follow the consensus rules. Good nodes do not listen to those who do not follow the consensus. Validating the consensus in that every node does when receiving the block. This way you have near real-time sync of package info and threat detection.
Mistake no.2 (again I don don't blame anyone - it took me several years to separate blockchain technology from blockchain hype). Proof-of-work is a consensus algorithm for ledgers (accounting books) which designed to solve double spending problem. PyPI is not a ledger, so it is totally irrelevant here. Blockchain is a signed chain of signed blocks. In case of PyPI, one block can be just one package data. The agreement, who can add the blocks is the consensus. "Every user with an account in PyPI can add block" may be a valid rule. "Only blocks that are signed with offline keys" may be a valid rule (although this can be extended to "keys that are signed by offline keys"). "Only users who have the most balance" is not the valid rule for PyPI, but it is another consensus for public ledgers called proof-of-stake.
How packagers sign their packages if TUF private keys are offline? What are pinned keys? My 5 years old have just read from Wikipedia that public keys pinning for HTTP was considered deprecated, and my search query for Unfortunately, without understanding if TUF pinned keys are similar to HTTP pinning keys, I can not comment on if they can really replace Merkle Tree in validating the current state of repository. The state in Merkle Tree not only covers specific package, it coverts the state of all packages at the moment it is generated. If the pinned key signs the state of repository, then it brings another question. Who owns pinned keys? (package maintainer, PyPI admin, TUF admin)
This doesn't answer the original question - how specifically to sign PyPI packages with
I haven't found https://fwupd.org/ in the list, so it is hard for to me to accept this argument against it. If TUF security is provided by offline keys, so does the https://fwupd.org/ but without the complications imposed by TUF. https://fwupd.org/ distributes packages signed/encrypted by vendor key (TUF |
|
I haven't found https://fwupd.org/ in the list, so it is hard for to me
to accept this argument against it. If TUF security is provided by offline
keys, so does the https://fwupd.org/ but without the complications
imposed by TUF. https://fwupd.org/ distributes packages signed/encrypted
by vendor key (TUF offline keys), and BIOS and other hardware (according
to UEFI spec) will not update itself if the signature doesn't match
hardcoded public key (TUF out-of-band channel). So the security of TUF
and https://fwupd.org/ are equivalent.
From the https://fwupd.org/lvfs/docs/developers site under "Is updating
firmware secure?"
In both the LVFS and fwupd, GPG crypto is being performed using GnuPG and
PKCS#7 crypto is using GnuTLS. The fwupd daemon has no network access and
only acts as the mechanism for clients using D-DBus and PolicyKit. Some
devices also have additional hardware signature verification schemes
implemented by the device manufacturer.
The LVFS and fwupd codebases have had several independent security audits.
The LVFS has a huge number of tests run for each commit
<https://travis-ci.org/hughsie/lvfs-website>, and fwupd has a comprehensive
test suite <https://travis-ci.org/hughsie/fwupd>, and is regularly scanned
using both clang and Coverity <https://scan.coverity.com/projects/10744>.
The threat model implied here is that they sign something and are careful
with the key. There is no talk about how they handle key revocation, etc.
TUF focuses on dealing with compromises. Not only just keys, but of
servers and other parts of the infrastructure. Of course, we've had audits
too (which you can find linked on the project site), but the system is
designed to resist and securely recover from a compromise of keys, servers,
etc. So the threat model and goals are very different. (You can find a lot
more about TUF's goals by reading this page, especially the Mitigating Key
Risk portion https://theupdateframework.io/security/ )
The website also has a lot of technical papers that describe the security
differences in much greater detail over solutions that use a single key for
signing, such as the project you mentioned.
How packagers sign their packages if TUF private keys are offline?
There are different keys in TUF. Some keys (like the root keys and some
targets keys) are offline. Others are held by the developers.
To try to give the five year old version. If you have a small project on
your own, you have your key for your project. If you have a group project,
you can choose if one person has the key, if multiple people have to use
keys, etc.
Just so you're not confused about pinning, this isn't HTTP pinning. The
reasons why HTTP pinning is deprecated don't make sense in this context
because you don't have hundreds of potentially valid roots of trust
(trusted CAs) and have to deal with the problems with having something
incorrectly pinned to the incorrect version. PyPI's targets role handles
this namespacing unambiguously.
…On Tue, Aug 31, 2021 at 11:02 PM Anatoli Babenia ***@***.***> wrote:
@mnm678 <https://github.com/mnm678> first, thanks for the explanation.
Some nerdy guys like me are completely senseless to people when it comes to
"defending the truth". ) I try not to criticize, but when I fail, please
forgive me.
However, it's not always practical to have a network of trusted nodes for
software distribution,
That's an mistake no.1 (hope you don't mind the terminology, but I don't
know another word). Nodes in blockchain are not trusted. They follow the
consensus rules. Good nodes do not listen to those who do not follow the
consensus. Validating the consensus in that every node does when receiving
the block. This way you have near real-time sync of package info and threat
detection.
and it takes a lot of computation to do the proof-of-work necessary to add
new items to a blockchain.
Mistake no.2 (again I don don't blame anyone - it took me several years to
separate blockchain technology from blockchain hype). Proof-of-work is a
consensus algorithm for ledgers (accounting books) which designed to solve
double spending problem. PyPI is not a ledger, so it is totally irrelevant
here. Blockchain is a signed chain of signed blocks. In case of PyPI, one
block can be just one package data. The agreement, who can add the blocks
is the consensus. "Every user with an account in PyPI can add block" may be
a valid rule. "Only blocks that are signed with offline keys" may be a
valid rule (although this can be extended to "keys that are signed by
offline keys"). "Only users who have the most balance" is not the valid
rule for PyPI, but it is another consensus for public ledgers called
proof-of-stake.
TUF instead takes the existing package manager approach, and uses offline
keys, revocation, and pinned keys to ensure that a compromise of the
repository can be detected and recovered from. Using the blockchain
analogy, TUF uses pinned root keys instead of a Merkle Tree hash to
validate the state of the repository. This has the advantage that the
pinned root keys remain valid through updates to the repository.
How packagers sign their packages if TUF private keys are offline?
What are pinned keys? My 5 years old have just read from Wikipedia
<https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning> that public keys
pinning for HTTP was considered deprecated, and my search query for pinned
keys <https://www.google.com/search?client=firefox-b-d&q=pinned+keys>
show a lot of articles that do not recommend this technique.
Unfortunately, without understanding if TUF pinned keys are similar to
HTTP pinning keys, I can not comment on if they can really replace Merkle
Tree in validating the current state of repository. The state in Merkle
Tree not only covers specific package, it coverts the state of all packages
at the moment it is generated. If the pinned key signs the state of
repository, then it brings another question.
Who owns pinned keys? (package maintainer, PyPI admin, TUF admin)
This model has already been mostly adopted by PyPI, as well as many
others, so it is certainly possible to implement.
This doesn't answer the original question - how specifically to sign PyPI
packages with offline keys, and which out-of-band channels PyPI users
should use for keys distribution. A simple example for a monkey who wants
to upload package to PyPI in the most secure manner would do.
I don't know the details about https://fwupd.org/ specifically, but
numerous supply chain security compromises of production systems occur
because of a repository or key compromise. TUF mitigates these risks
through the use of offline keys, threshold delegations, and namespacing.
I haven't found https://fwupd.org/ in the list, so it is hard for to me
to accept this argument against it. If TUF security is provided by offline
keys, so does the https://fwupd.org/ but without the complications
imposed by TUF. https://fwupd.org/ distributes packages signed/encrypted
by vendor key (TUF offline keys), and BIOS and other hardware (according
to UEFI spec) will not update itself if the signature doesn't match
hardcoded public key (TUF out-of-band channel). So the security of TUF
and https://fwupd.org/ are equivalent.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5247 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGRODZNNGUXZ645HQTIKALT7TVHBANCNFSM4GNHO6PQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
@JustinCappos that's a valid point, and a tough problem. if anyone can explain in those childish terms how the handling is done, that would clear up my doubts. Right now I understand this as if offline keys are lost, everything is lost. The same way if private key on the blockchain is lost. On the blockchain the problem is solved with multisignature keys, so that you need 3 out of 5 signatures to make multisig valid. There are also extensions that allow to migrate valid multisig to another multisig with no missing keys.
@trishankatdatadog yes, I've read it (after asking), and I like TL very much. I think it is a way to go. So far it seemd that While I don't think that TUF is the way to go, I think it may have some good ideas on how to manage signing keys, so instead of following TUF or using combined TF+TUF, there may be a slimmed down version of security framework, that reuses components from both and also leverages some best practices from blockchain technology (like real-time sync, notifications and caching). |
|
Hello @abitrolly! I appreciate your engagement and concern with the security of PyPI shown in this discussion. However, there are multiple points in the recent conversation where you have chosen to belittle or dismiss things as "childish" and comparing efforts of those involved to 5 year olds. This isn't very respectful of the effort and time that people have put into this work. I'd like to ask you to review the PSF Code of Conduct, which this repository and discussion adheres, before further disrespectful behavior becomes an issue. |
Consider that if something looks complicated, there might be good reasons for it, especially if it was designed with a threat model with nation-state attackers in mind. Feel free to use TLs all you like, but the PyPA consensus has been for TUF, with the community free to record TUF metadata on TLs if they wish, thus getting the best of both worlds. |
|
@ewdurbin all I wanted is to receive a layperson-friendly explanation as it happens in https://www.reddit.com/r/explainlikeimfive/ which I've subscribed to. I apologize that I haven't referenced it in the first place. Does that clarify that the phrase "explain me like I am five" is not done to belittle or dismiss things as "childish", or offend those who put many efforts in developing and promoting TUF?
I acknowledge time and effort that people put into developing TUF and trying to include it into Python distribution index. If the critics of TUF framework itself is seen as disrespectful behavior, then it will be better for me to leave the people to their business. |
|
Thanks for your feedback. IMHO, Sigstore should be (1) at least rooted in a trustless blockchain; and (2) using ld-proofs and W3C CCG Cryptographic Signature Suite URIs for future-proofing. That aside, how can Sigstore and TUF work together? Is there a good ELI5 graphic of the PyPI TUF package build and release workflow, and maybe also a complete sequence diagram? |
|
In a rush, but quickly wanted to point out that Sigstore uses TUF...
https://dlorenc.medium.com/using-the-update-framework-in-sigstore-dc393cfe6b52
…On Fri, Sep 3, 2021 at 11:32 PM Wes Turner ***@***.***> wrote:
Thanks for your feedback.
IMHO, Sigstore *should* be (1) at least rooted in a *trustless* blockchain;
and (2) using ld-proofs and W3C Signature Suite URIs. That aside, how can
Sigstore and TUF work together?
Is there a good ELI5 graphic of the PyPI TUF package build and release
workflow, and maybe also a complete sequence diagram?
https://en.wikipedia.org/wiki/Sequence_diagram
![Sigstore architecture summary]
(https://www.sigstore.dev/img/system_architecture_summary-01.svg)
On Fri, Sep 3, 2021, 04:42 Anatoli Babenia ***@***.***> wrote:
> @ewdurbin <https://github.com/ewdurbin> all I wanted is to receive a
> layperson-friendly explanation as it happens in
> https://www.reddit.com/r/explainlikeimfive/ which I've subscribed to. I
> apologize that I haven't referenced it in the first place. Does that
> clarify that the phrase "explain me like I am five" is not done to
belittle
> or dismiss things as "childish", or offend those who put many efforts in
> developing and promoting TUF?
>
> I'd like to ask you to review the PSF Code of Conduct, which this
> repository and discussion adheres, before further disrespectful behavior
> becomes an issue.
>
> I acknowledge time and effort that people put into developing TUF and
> trying to include it into Python distribution index. If the critics of
TUF
> framework itself is seen as disrespectful behavior, then it will be
better
> for me to leave the people to their business.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#5247 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAAMNSZ2CYOUPZMLY3R6GG3UACC6DANCNFSM4GNHO6PQ
>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
>
> or Android
> <
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
>.
>
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5247 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGROD3S22WGH66XULSHY7DUADS7JANCNFSM4GNHO6PQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
I'm not: (1) sure that there is such a thing as a "trustless" blockchain, and (2) familiar with these technologies. However, Marina and I wrote a blog post about how you can combine TUF and transparent/tamper-evident logs such as sigstore. TLDR: you can publish TUF timestamp metadata on sigstore. My upcoming talk at SupplyChainSecurityCon will discuss how the Datadog Agent integrations is the first transparent, compromise-resilient software publication pipeline in the world.
I don't think there is one right now, but perhaps you could help us make one using the descriptions from PEPs 458 and 480? |
Yes. This will be a separate TUF repository for open source projects, distinct from the one for PyPI right now. However, PyPI can publish its own TUF timestamps to sigstore. |
This comment has been minimized.
This comment has been minimized.
|
I've published a roadmap for the PEP 458 rollout in #10672. Please note that this issue is for PEP 458-related development work only, and is not a place to discuss TUF alternatives, issues with TUF as a framework, or ask for explanations on how TUF works. |
Is it possible to get an update on the development roadmap about when TUF or other encryption support might be deployed? Thanks!
Also, it appears that tomorrow will be 6 years since January 5, 2013.
The text was updated successfully, but these errors were encountered: