python-tuf
python-tuf copied to clipboard
theupdateframework
Tap 14 draft pr
• Commits fc5bd5c to 88c140a are based around setting up a sample metadata structure inside the repository folder (which is inside repository_data) for testing
• 774a039 is for reverting repository back to its original state and 8845ebd stores the metadata inside a new TAP 14 folder
• df46e38 and 0f50945 add test functions that check inside the TAP 14 folder
• Currently working on implementing changes to the client update process inside the updater.py file
Pull Request Test Coverage Report for Build 2621327940
- 3 of 9 (33.33%) changed or added relevant lines in 1 file are covered.
- No unchanged relevant lines lost coverage.
- Overall coverage decreased (-0.5%) to 97.609%
| Changes Missing Coverage | Covered Lines | Changed/Added Lines | % |
|---|---|---|---|
| tuf/ngclient/updater.py | 3 | 9 | 33.33% |
| <!-- | Total: | 3 | 9 |
| Totals | |
|---|---|
| Change from base Build 2609032759: | -0.5% |
| Covered Lines: | 1304 |
| Relevant Lines: | 1326 |
💛 - Coveralls
@abs007 as the changes are a lot could you chime in and explain your thoughts on the TAP 14 implementation? Now as you have some experience with that you have a valuable perspective on that and as it seems there is no full consensus on that feature https://github.com/theupdateframework/python-tuf/issues/2040 it will be good to hear your opinion.
So currently I along with @mnm678 and @znewman01 are working on implementing the changes to how a client would be downloading the metadata according to the format in the TAP 14 specification. This means tinkering with the updater.py file to add new functionality.
I know this is still a draft but I'll leave a quick comment: I don't understand why the client needs this functionality and before this PR is made ready I would like to see a comment in #2040 that explains the real world use case: how is this useful for python-tuf users?
Background for my confusion: If a repository starts offering multiple versions of the repository, why can't clients decide to "upgrade" using a plain old software update on the client, so that the client just switches from old to new repository URL? (I'm obviously assuming that the python-tuf version used supports both versions of the spec -- but so does this proposal I think)
In practice, if a future TUF-enabled pypi.org made available a second repository using a newer TUF spec features I think it would be totally appropriate for pip, the client, to simply change the used repo URL to the new repository in a pip software update. What advantage is there in making this repository selection dynamic?
Thanks for the question, will get back to you soon. But in the meantime, can we move this discussion back to the associated Issue from this PR, since you’re raising questions about the utility of the feature itself?
On Aug 7, 2022, at 1:10 PM, Jussi Kukkonen @.***> wrote:
I know this is still a draft but I'll leave a quick comment: I don't understand why the client needs this functionality and before this PR is made ready I would like to see an issue opened that explains the real world use case: how is this useful for python-tuf users?
Background for my confusion: If a repository starts offering multiple versions of the repository, why can't clients decide to "upgrade" using a plain old software update on the client, so that the client just switches from old to new repository URL? (I'm obviously assuming that the python-tuf version used supports both versions of the spec -- but so does this proposal I think)
In practice, if a future TUF-enabled pypi.org made available a second repository using a newer TUF spec features I think it would be totally appropriate for pip, the client, to simply change the used repo URL to the new repository in a pip software update. What advantage is there in making this repository selection dynamic?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
