-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
post a Debian RFP (Request for Package) #263
Comments
Here is a proposal. Header This is what I suggest as the header.
Who is the upstream author? I mean, who's name can replace 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.
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. |
Ping? |
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: #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. |
Ping? :) |
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. |
Any update? |
@adrelanos Could you help us send one, please? |
Already done. See #263 (comment). |
@adrelanos I see, sorry, my bad, I missed this. What can we do to help? Do you need someone to post the RFP? |
#263 (comment) 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:
I already have a volunteer for in-toto, which will hopefully also get in securesystemslib, which we need for TUF as well. |
Thanks @lukpueh! |
Update: In addition to filing an RFS/ITP bug as mentioned above, I also filed an actual ITP bug, and updated 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 |
That would be great, thanks @rzr! |
This will help packaging effort Relate-to: theupdateframework#263 Signed-off-by: Philippe Coval <[email protected]> Change-Id: I60cf8c5fdbe6aa4b44aebadb7f4bc13c546ad159
Hi, Let me share some updates about this task. I have just applied to join this team: I intend to do the initial integration, if previous packagers want to be mentored let me know 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 |
This change is needed for debian packaging effort of latest release 0.17.0 theupdateframework#263 Because this key update is critical in the trust's chain, may I request upstream to double check and acknowledge this change. This key was obtained from WoT using: wget https://files.pythonhosted.org/packages/3a/7d/d1cadc8c68cdfe035412ca11a2fa3105a0a3fd18e4212053cf8f67bdd02a/tuf-0.17.0.tar.gz wget https://files.pythonhosted.org/packages/3a/7d/d1cadc8c68cdfe035412ca11a2fa3105a0a3fd18e4212053cf8f67bdd02a/tuf-0.17.0.tar.gz.asc gpg --verify tuf-0.17.0.tar.gz.asc gpg: assuming signed data in 'tuf-0.17.0.tar.gz' gpg: Signature made Thu 25 Feb 2021 12:42:50 PM CET gpg: using RSA key 08F3409FCF71D87E30FBD3C21671F65CB74832A4 gpg: Can't check signature: No public key gpg --recv-key 08F3409FCF71D87E30FBD3C21671F65CB74832A4 \ --keyserver hkp://keys.gnupg.net gpg --verify ../tuf-0.17.0.tar.gz.asc gpg --fingerprint 08F3409FCF71D87E30FBD3C21671F65CB74832A4 # pub rsa3072 2020-03-17 [SC] [expires: 2030-03-15] # 08F3 409F CF71 D87E 30FB D3C2 1671 F65C B748 32A4 # uid [ unknown] Joshua Lock (GPG on YubiKey) <[email protected]> # sub rsa3072 2020-03-17 [E] [expires: 2030-03-15] # sub rsa3072 2020-03-17 [A] [expires: 2030-03-15] gpg --armor --export 08F3409FCF71D87E30FBD3C21671F65CB74832A4 \ > debian/upstream/signing-key.asc Cc: Sebastien Awwad <[email protected] @awwad> Cc: Lukas Puehringer <[email protected] @lukpueh> Cc: Joshua Lock <[email protected] @joshuagl> Relate-to: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#signing-key Origin: https://github.com/CrossStream/tuf/tree/debian/master Forwarded: https://github.com/theupdateframework/tuf/pulls/rzr Signed-off-by: Philippe Coval <[email protected]>
This change is needed for debian packaging effort of latest release 0.17.0 theupdateframework#263 Because this key update is critical in the trust's chain, may I request upstream to double check and acknowledge this change. This key was obtained from WoT using: wget https://files.pythonhosted.org/packages/3a/7d/d1cadc8c68cdfe035412ca11a2fa3105a0a3fd18e4212053cf8f67bdd02a/tuf-0.17.0.tar.gz wget https://files.pythonhosted.org/packages/3a/7d/d1cadc8c68cdfe035412ca11a2fa3105a0a3fd18e4212053cf8f67bdd02a/tuf-0.17.0.tar.gz.asc gpg --verify tuf-0.17.0.tar.gz.asc gpg: assuming signed data in 'tuf-0.17.0.tar.gz' gpg: Signature made Thu 25 Feb 2021 12:42:50 PM CET gpg: using RSA key 08F3409FCF71D87E30FBD3C21671F65CB74832A4 gpg: Can't check signature: No public key gpg --recv-key 08F3409FCF71D87E30FBD3C21671F65CB74832A4 \ --keyserver hkp://keys.gnupg.net gpg --verify ../tuf-0.17.0.tar.gz.asc gpg --fingerprint 08F3409FCF71D87E30FBD3C21671F65CB74832A4 # pub rsa3072 2020-03-17 [SC] [expires: 2030-03-15] # 08F3 409F CF71 D87E 30FB D3C2 1671 F65C B748 32A4 # uid [ unknown] Joshua Lock (GPG on YubiKey) <[email protected]> # sub rsa3072 2020-03-17 [E] [expires: 2030-03-15] # sub rsa3072 2020-03-17 [A] [expires: 2030-03-15] gpg --armor --export 08F3409FCF71D87E30FBD3C21671F65CB74832A4 \ > debian/upstream/signing-key.asc Cc: Sebastien Awwad <[email protected] @awwad> Cc: Lukas Puehringer <[email protected] @lukpueh> Cc: Joshua Lock <[email protected] @joshuagl> Relate-to: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#signing-key Origin: https://github.com/CrossStream/tuf/tree/debian/master Forwarded: theupdateframework#1299 Signed-off-by: Philippe Coval <[email protected]>
Those generated files are not explicitly under Apache-2.0 licence and AFAIK they can not be regenerated from missing (latex?) sources It would help to have those files accessible elsewhere to avoid licence mixup. Debian had to repack the source package to make tarball compliant with DFSG dispite debian tools are known to be trustworthy, this extra step would add weakess in the chain of trust Cleanup done upstream would make distribution safer Relate-to: theupdateframework#263 (comment) Signed-off-by: Philippe Coval <[email protected]>
Those generated files are not explicitly under Apache-2.0 licence and AFAIK they can not be regenerated from missing (latex?) sources. To avoid licence mixup. It would help to have those files published elsewhere. Meanwhile online (Github) links are used. Debian had to repack the source package to make tarball compliant with DFSG dispite debian tools are known to be trustworthy, this extra step would add weakess in the chain of trust Cleanup done upstream would make distribution safer. Bug: theupdateframework#1161 Bug-Debian: https://salsa.debian.org/python-team/packages/tuf/-/merge_requests/11 Relate-to: theupdateframework#263 (comment) Signed-off-by: Philippe Coval <[email protected]>
Those generated files are not explicitly under Apache-2.0 licence and AFAIK they can not be regenerated from missing (latex?) sources. To avoid licence mixup. It would help to have those files published elsewhere. Meanwhile online (Github) links are used. Debian had to repack the source package to make tarball compliant with DFSG despite debian tools are known to be trustworthy, this extra step would add weakess in the chain of trust Cleanup done upstream would make distribution safer. Bug: theupdateframework#1161 Bug-Debian: https://salsa.debian.org/python-team/packages/tuf/-/merge_requests/11 Relate-to: theupdateframework#263 (comment) Forwarded: theupdateframework#1380 Signed-off-by: Philippe Coval <[email protected]>
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... |
Duplication is not needed since files are hosted in website project: https://github.com/theupdateframework/theupdateframework.io/tree/master/static/papers Those generated files are not explicitly under Apache-2.0 licence and AFAIK they can not be regenerated from missing (latex?) sources. To avoid licence mixup. It would help to have those files published elsewhere. Meanwhile online (Github) links are used. Debian had to repack the source package to make tarball compliant with DFSG despite debian tools are known to be trustworthy, this extra step would add weakess in the chain of trust Cleanup done upstream would make distribution safer. Bug: theupdateframework#1161 Bug-Debian: https://salsa.debian.org/python-team/packages/tuf/-/merge_requests/11 Relate-to: theupdateframework#263 (comment) Forwarded: theupdateframework#1380 Relate-to: theupdateframework/specification#160 Signed-off-by: Philippe Coval <[email protected]>
Great job @rzr |
Duplication is not needed since files are hosted in website project: https://github.com/theupdateframework/theupdateframework.io/tree/master/static/papers Those generated files are not explicitly under Apache-2.0 licence and AFAIK they can not be regenerated from missing (latex?) sources. To avoid licence mixup. It would help to have those files published elsewhere. Meanwhile online (Github) links are used. Debian had to repack the source package to make tarball compliant with DFSG despite debian tools are known to be trustworthy, this extra step would add weakess in the chain of trust Cleanup done upstream would make distribution safer. Bug: #1161 Bug-Debian: https://salsa.debian.org/python-team/packages/tuf/-/merge_requests/11 Relate-to: #263 (comment) Forwarded: #1380 Relate-to: theupdateframework/specification#160 Signed-off-by: Philippe Coval <[email protected]>
This change is needed for debian packaging effort of latest release 0.17.0 theupdateframework#263 Because this key update is critical in the trust's chain, may I request upstream to double check and acknowledge this change. This key was obtained from WoT using: wget https://files.pythonhosted.org/packages/3a/7d/d1cadc8c68cdfe035412ca11a2fa3105a0a3fd18e4212053cf8f67bdd02a/tuf-0.17.0.tar.gz wget https://files.pythonhosted.org/packages/3a/7d/d1cadc8c68cdfe035412ca11a2fa3105a0a3fd18e4212053cf8f67bdd02a/tuf-0.17.0.tar.gz.asc gpg --verify tuf-0.17.0.tar.gz.asc gpg: assuming signed data in 'tuf-0.17.0.tar.gz' gpg: Signature made Thu 25 Feb 2021 12:42:50 PM CET gpg: using RSA key 08F3409FCF71D87E30FBD3C21671F65CB74832A4 gpg: Can't check signature: No public key gpg --recv-key 08F3409FCF71D87E30FBD3C21671F65CB74832A4 \ --keyserver hkp://keys.gnupg.net gpg --verify ../tuf-0.17.0.tar.gz.asc gpg --fingerprint 08F3409FCF71D87E30FBD3C21671F65CB74832A4 # pub rsa3072 2020-03-17 [SC] [expires: 2030-03-15] # 08F3 409F CF71 D87E 30FB D3C2 1671 F65C B748 32A4 # uid [ unknown] Joshua Lock (GPG on YubiKey) <[email protected]> # sub rsa3072 2020-03-17 [E] [expires: 2030-03-15] # sub rsa3072 2020-03-17 [A] [expires: 2030-03-15] gpg --armor --export 08F3409FCF71D87E30FBD3C21671F65CB74832A4 \ > debian/upstream/signing-key.asc Cc: Sebastien Awwad <[email protected] @awwad> Cc: Lukas Puehringer <[email protected] @lukpueh> Cc: Joshua Lock <[email protected] @joshuagl> Relate-to: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#signing-key Origin: https://github.com/CrossStream/tuf/tree/debian/master Forwarded: theupdateframework#1299 Signed-off-by: Philippe Coval <[email protected]>
Change-Id: Ib59e8dd0b489b48b210efb51915b7135695d1438 Fordwarded: theupdateframework#1300 Relate-to: theupdateframework#263 Signed-off-by: Philippe Coval <[email protected]>
It was removed since v0.15.0 Thanks-to: <Lukas Puehringer <[email protected]> Relate-to: theupdateframework#263 Signed-off-by: Philippe Coval <[email protected]>
Change-Id: I4f19349f135bff1fce3590143900fa7c63d21c5d Relate-to: theupdateframework#263 Signed-off-by: Philippe Coval <[email protected]>
Because they can't be regenerated from (missing) sources Relate-to: theupdateframework#263 (comment) Cc: <@tumbleweed> Signed-off-by: Philippe Coval <[email protected]>
Exclude DFSG-nonfree files (.pdf) For some reasons: gbp import-orig --uscan can't be used, prefer: uscan -dd && gbp import-orig ../*+dfsg.orig.tar.xz --pristine-tar Also reformat and sort watch file for readability Cc: @tumbleweed Relate-to: theupdateframework#263 (comment) Signed-off-by: Philippe Coval <[email protected]>
Hi, I'll need your help to clarify some licencing see: please comment: 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
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 |
Those patches should net be forwarded to upstream's main branch Relate-to: theupdateframework#263
Applied-Upstream: theupdateframework#1337 Relate-to: theupdateframework#263
Those patches should net be forwarded to upstream's main branch Relate-to: theupdateframework#263 Signed-off-by: Philippe Coval <[email protected]>
Relate-to: theupdateframework#263 Signed-off-by: Philippe Coval <[email protected]>
Applied-Upstream: theupdateframework#1337 Relate-to: theupdateframework#263 Signed-off-by: Philippe Coval <[email protected]>
Signed-off-by: Stefano Rivera <[email protected]> Relate-to: theupdateframework#263 Signed-off-by: Philippe Coval <[email protected]>
Applied-Upstream: theupdateframework#1337 Relate-to: theupdateframework#263 Signed-off-by: Philippe Coval <[email protected]>
Feel free to merge this patch series coming for debian packaging team: Then rebase on latest release and then eventually sync back to debian, |
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.
The text was updated successfully, but these errors were encountered: