python-tuf
python-tuf copied to clipboard
theupdateframework
post a Debian RFP (Request for Package)
This is a formal step that should be done to get software packaged for Debian. (Related: #259 #129 #262)
More info on RFP: https://wiki.debian.org/RFP
Example RFPs: https://www.debian.org/devel/wnpp/requested
The purpose of this ticket is to write a draft and to post it on the Debian tracker.
Here is a proposal.
Header
This is what I suggest as the header.
* Package name : python-tuf
Version : 0.99
Upstream Author : Name <[email protected]>
* URL : http://theupdateframework.com/
* License : BSD
Programming Lang: Python
Description : Like the S in HTTPS, a plug-and-play library for securing a software updater
Who is the upstream author? I mean, who's name can replace Name <[email protected]>? And who's e-mail address can be used in this non-encoded form?
License is correct? Any else that needs fixing?
Body
A more detailed description belongs into the body.
I suggest, we leave out the current progress (#259) in the original post. Mixing the request with technical discussion seems wrong. We can add separate mail were we discuss technical progress.
TUF (The Update Framework) helps developers secure their new or existing software update systems. Software update systems are vulnerable to many known attacks, including those that can result in clients being compromised or crashed. TUF helps solve this problem by providing a flexible security framework that can be added to software updaters.
TUF is [currently being / will / might soon?] be implemented into python-pip [...?].
TUF is being developed by ... [the same people?] that ... wrote the paper on package manager security that resulted in ... [1]
[1] http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html
Could you fill out the gaps please? And could you go on a bit please? Tell why it would be great and perhaps needed to get TUF into Debian and why you are great and serious [cooperation with, developed since]?
Feel free to either just edit, correct, rewrite my draft or to post alternative drafts below.
It doesn't really matter who posts it. Anyone can post an RFP. It's like a Debian feature request "can you package that please". No formal relation to the upstream project required or so. So I don't mind if in the end you post or me.
Hi Adrelanos,
Thanks for staying on top of this feature request! Your ping came just in time.
Since TUF v0.99, we have been busy trying to finalize TUF v1.0. We had previously made improvements to the framework in terms of security and efficiency. These improvements are covered in the Diplomat paper (secure delegations for community repositories) that was accepted to NSDI 2016, and in another paper that will soon be submitted to a conference.
More recently, we have been trying to make minor design changes to the framework that you can review here: https://github.com/theupdateframework/tuf/pull/326. These final touches were mainly to modify how the delegations are organized on the repository, and to give developers and repository maintainers more freedom in how they delegate trust of packages.
Once PR #326 is reviewed, we'll be free to finally work on your feature request. It'd be nice to submit a Debian RFP for a version of the framework that contains our latest work.
Thanks, Patrick. There have been some changes in developer availability, so now I'm taking a look at the broader Debian packaging issue. I'll have more by tomorrow.
Already done. See https://github.com/theupdateframework/tuf/issues/263#issuecomment-73368366.
@adrelanos I see, sorry, my bad, I missed this. What can we do to help? Do you need someone to post the RFP?
https://github.com/theupdateframework/tuf/issues/263#issuecomment-73368366 could use a review and comes with some open questions.
Feel free to either just edit, correct, rewrite my draft or to post alternative drafts below.
It doesn't really matter who posts it. Anyone can post an RFP. It's like a Debian feature request "can you package that please". No formal relation to the upstream project required or so. So I don't mind if in the end you post or me.
Thanks for your initiative, @adrelanos! I am in the process of packaging TUF's sister project, in-toto, for Debian. I have just uploaded securesystemslib (the crypto and metadata library that both TUF and in-toto use) to mentors.debian.net.
I would like to fix the Lintian errors and upload in-toto as well and then ping up some Debian developers, who I met at MiniDebConf in Hamburg last week, and ask them to sponsor my maintainership.
Once that's through, I can do the same thing for TUF.
Thanks for picking up the ball, Lukas, I dropped this due to work...
Quick status update, I have:
- debianized TUF (https://github.com/theupdateframework/tuf/commit/a2532a15424fc667c4423f1795cfb7ea3399ea92),
- built and uploaded it to mentors.debian.net/package/python-tuf, and
- filed an RFS/ITP bug.
I already have a volunteer for in-toto, which will hopefully also get in securesystemslib, which we need for TUF as well.
Update:
In addition to filing an RFS/ITP bug as mentioned above, I also filed an actual ITP bug, and updated debian/changelog to reference it, which also satisfies a lintian requirement.
Moreover, I adopted review comments I received from a Debian developer for securesystemslib and in-toto metadata on the TUF debian metadata too (see recent commits on tuf@debian).
The package, built with the new metadata, can be found on mentors.debian.net/package/python-tuf.
We're blocked on Debian: we need to find a sponsor for the package...
hi, I can help on this as Debian maintainer ( https://qa.debian.org/[email protected] ) I won't be able to upload anything but i can share my experience and I would try to see if python team would be interested into co-maintenance.
https://mentors.debian.net/package/python-tuf/ is no more online
Hi, Let me share some updates about this task.
I have just applied to join this team: https://lists.debian.org/debian-python/2021/03/msg00005.html
I intend to do the initial integration, if previous packagers want to be mentored let me know we can share the effort, but as you might know Debian 11 is now entering the freeze period, so next release should be the target.
Meanwhile I have shared packages of latest to my personal repository at:
https://build.opensuse.org/project/show/home:rzrfreefr:latest
More to come soon
Hi, Some updates on this effort, I am now part of debian python team so I was able to create this project
https://salsa.debian.org/python-team/packages/python-tuf/-/merge_requests
As said previously I'll use pypi packages as source, but I'll forward my patches to upstream debian branch
Please review this 1st batch: https://github.com/theupdateframework/tuf/pull/1300 and I'll open PR for remaining ones
Hi,
Debian's Python Team (DPT) has a some concerns about licensing of papers, are they compatible with DFSG ?:
https://www.debian.org/social_contract#guidelines
Check related thread: https://lists.debian.org/debian-legal/2002/03/msg00104.html
BTW let me thank @tumbleweed from DTP
Also it would make sense to ship document sources (latex?) in tree and make it clear that they can be redistributed under project license (Apache-2.0).
https://lists.debian.org/debian-legal/2002/03/msg00114.html
Finally a "manifest" file would help to identify licenses and copyrights for each file.
In debian we use debian/copyright but maybe there is an other standard to describe this upstream's side (I know SWH uses some semantics for that).
Any option to share? If none I'll suggest to relocate them to separate project.
cc: @joshuagl , @jku
I don't think we should ship papers as part of the packaging, even if they live in this repo. We have an issue to clean up what we include in the packaging (amongst other things #1161)
Update: https://ftp-master.debian.org/new/tuf_0.17.0+dfsg-1.html \o/
I'll sync my changes to upstream's debian branch once published in unstable archive...
Hi,
I'll need your help to clarify some licencing see:
please comment: https://salsa.debian.org/python-team/packages/tuf/-/merge_requests/12
Or please update readme file to identify files coming from tor.
This dual licencing is unclear and rejected by debian :(
The lazy option would be use plain Apache-2.0 if applicable.
To clarify what I was saying there (I'm "tumbleweed on IRC):
From my understanding, the people who care about such things don't think BSD-3 is really compatible with MIT-style licenses, because it's slightly more restrictive. However, the restriction is debatably moot, so you're probably OK.
Also saying
Many files are modified from Thandy and are licensed under the following license:
doesn't clarify the licensing situation, it muddies it. We don't know which files these are. And if we do the research (as above) it seems that those shouldn't be incorporated into an MIT-style license.
Debian probably needs to describe this as (Apache OR Expat) dual-licensing, no mention of BSD. Or ignore the Expat/BSD mix, and say the one thing we can be sure about is that this is Apache-licensed.
May a new issue be created, but meanwhile here are related links:
https://github.com/gsathya/thandy/blob/master/LICENSE
https://hackmd.io/jdAk9rmPSpOYUdstbIvbjw
https://app.slack.com/client/T08PSQ7BQ/C8NMD3QJ3/thread/C8NMD3QJ3-1624384442.076800
Feel free to merge this patch series coming for debian packaging team:
https://github.com/theupdateframework/python-tuf/pull/1872
Then rebase on latest release and then eventually sync back to debian, I could help on this but my "free" time is limited for now.