Re: Notes on packaging PCYNLITX
Sorry for late posting. Currently I don't see any applications that use PCYNLITX. Regarding code examples, the upstream provide some of them [1]. Those are in PDF format, though, so manually copy-pasting is needed to use them. [1]: https://www.pcynlitx.tech/code-examples/ On 24/07/19 04.24, Tomas Pospisek wrote: Hi, I have a few rather higher level questions about PCYNLITX. * are there any known users of PCYNLITX, in the sense of, does there exist an application, that actually uses PCYNLITX? * I have read through the web page of PCYNLITX. I can not make up my mind. The web page is talking about how well documented PCYNLITX is, but there's no code examples of how PCYNLITX is used, as far as I could find. Without that it's too hard for me to make up my mind about it. I find the concept interesting, but without seeing code - hmmm... ? *t Am 12.07.19 um 08:52 schrieb Bagas Sanjaya: Hello, I've filed RFP for PCYNLITX sometimes ago [1]: In PCYNLITX download page [2], it can be installed by using installation script. However, after examining install script, I noticed following: - PCYNLITX doesn't employ version numbering like any other project/packages. It would be difficult to identify which is the latest version. So I use version number 0.0~git20190606 in RFP report. - The script install wxWidgets library from third-party repository, not from Debian. It use codelite repo (for Stretch): apt-add-repository 'deb http://repos.codelite.org/wx3.0.4/debian/ stretch libs' - Evince will be installed as runtime dependency, possibly for documentation. For non-GNOME users (KDE, XFCE, etc.) which use different readers (like Okular and Atril) this can bloat their system and become unnecessary. - All steps are performed using sudo. If the script is run by root user, this will be redundant, since the installation is done by root privileges. If I will packaging PCYNLITX for Debian, any suggestions, assuming that I have read New Maintainers Guideline and related Debian packaging documentation? Cheers, Bagas [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931400 [2]: http://www.pcynlitx.tech/the-installation-of-pcynlitx/ -- An old man doll... just what I always wanted! - Clara -- An old man doll... just what I always wanted! - Clara
Re: tag2upload (git-debpush) service architecture - draft
Sam Hartman writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
> Sean Whitton writes:
> > Okay, thanks.
>
> > I think that the Git-Tag-Info field solves this. With that
> > field available, anyone can do the following to perform an
> > equivalent verification:
>
> > 1. fetch the .dsc from the archive
>
> > 2. fetch, from dgit-repos, the tag given in the Git-Tag-Info
> > field of the .dsc
>
> This violates the "no external data" requirement above.
This requirement can be met (as I mentioned before) by including the
tag object data as a file in the upload (listed in .changes). The
signature can be verified without any further data. A git bundle is
not needed.
I just need to know what filename I should give it.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: tag2upload (git-debpush) service architecture - draft
> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Re: tag2upload (git-debpush) service
Ian> architecture - draft"):
>> Sean Whitton writes: > Okay, thanks.
>>
>> > I think that the Git-Tag-Info field solves this. With that >
>> field available, anyone can do the following to perform an >
>> equivalent verification:
>>
>> > 1. fetch the .dsc from the archive
>>
>> > 2. fetch, from dgit-repos, the tag given in the Git-Tag-Info >
>> field of the .dsc
>>
>> This violates the "no external data" requirement above.
Ian> This requirement can be met (as I mentioned before) by
Ian> including the tag object data as a file in the upload (listed
Ian> in .changes). The signature can be verified without any
Ian> further data. A git bundle is not needed.
What do you mean by tag object data?
Can you outline how to get from the dsc to a verification of the tag
signature without contacting the dgit server?
Bug#933735: ITP: drawing -- drawing application for GNOME
Package: wnpp Severity: wishlist Owner: Andrej Shadura * Package name: drawing Version : 0.4.2 Upstream Author : Romain F.T. * URL : https://maoschanz.github.io/drawing/ * License : GPL-3 Programming Lang: Python Description : drawing application for GNOME This application is a basic image editor, similar to Microsoft Paint, but aiming at the GNOME desktop.
Re: tag2upload (git-debpush) service architecture - draft
Sam Hartman writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
> Ian Jackson writes:
> > This requirement can be met (as I mentioned before) by
> > including the tag object data as a file in the upload (listed
> > in .changes). The signature can be verified without any
> > further data. A git bundle is not needed.
>
> What do you mean by tag object data?
I mean the output of "git cat-file tag refs/tags/debian/".
Included as, say, _-.git-tag
and referenced in .changes.
> Can you outline how to get from the dsc to a verification of the tag
> signature without contacting the dgit server?
Sure.
Split the tag object daa at the relevant - boundary. This gives
you 1. an unsigned tag data file (first half) 2. a detached armoured
PGP signature (second half). Feed that pair to gpgv (with appropriate
keyrings etc.). That's it.
If information in the tag should be checked (eg, the intended source
package name or version, or the destination for the upload), this
should be parsed out of the "unsigned tag data file" half after
splitting, to avoid any possible attacks based on differences in
disassembly/parsing algorithms.
(Sample for this code can be found in dgit-repos-server and is already
deployed on the dgit git server; but it's not very hard.)
BTW, I thought the requirement was to be able to start with the upload
including the .changes, rather than necessarily with then .dsc, to do
this verification. We could put the tag data file in the .dsc but it
seems to me that it is not really helpful to consumers of the .dsc and
that really we are putting it in the upload for the benefit of the
archive. So the .changes is probably better. Putting it into the
.dsc would involve changing more things to tolerate it (ie, ignore
it) and seems like a layering violation - the .dsc is firmly
dpkg's territory.
But the approach I sketch above would work for the .dsc too of course.
HTH.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: tag2upload (git-debpush) service architecture - draft
> "Ian" == Ian Jackson writes: >> Can you outline how to get from the dsc to a verification of the >> tag signature without contacting the dgit server? Ian> Sure. Ian> Split the tag object daa at the relevant - boundary. This Ian> gives you 1. an unsigned tag data file (first half) 2. a Ian> detached armoured PGP signature (second half). Feed that pair Ian> to gpgv (with appropriate keyrings etc.). That's it. Ah, thanks. I think this helps me understand where the confusion is. My understanding of ftpmaster's requirement, confirmed by Bastian is that without data external to the dsc, someone needs to be able to confirm the contents of the source package are certified by a user in the Debian keyring. That is, anyone needs to be able to prove only from the dsc (and keyrings of course) that the dsc is created from the git objects intended by the signer. The output of git cat-file tag is insufficient to do that. All in includes is the object hash of the commit object. However, we don't have that commit object or the tree objects in the dsc. We could perform that verification given the dgit repository, but that would violate the no external data requirement from ftpmaster as I have explained to Sean. In effect, ftpmaster is saying they are uncomfortable trusting tag2upload very much. I think we may see this same issue come up again when we discuss automated sourceful NMUs as requested by the reproducible builds community.
Re: tag2upload (git-debpush) service architecture - draft
On 02/08/2019 19:09, Ian Jackson wrote:
Sam Hartman writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
Can you outline how to get from the dsc to a verification of the tag
signature without contacting the dgit server?
Sure.
Split the tag object daa at the relevant - boundary. This gives
you 1. an unsigned tag data file (first half) 2. a detached armoured
PGP signature (second half). Feed that pair to gpgv (with appropriate
keyrings etc.). That's it.
That only verifies that that user signed *something*, not what contents
they signed. To do that, you need to include both the tag object and
the commit object: the tree objects (i.e. lists of file/subtree hashes)
can be reconstructed from the files.
Also, in current git this package contents check is relying on SHA-1,
unless you put an extra hash in the tag message.
You can think of Git's hashes as like Debian's .dsc/.changes but with
more levels:
Git [0]: file -> tree ( -> tree...) -> commit -> tag
(One file hash per file ("blob"), one tree object per directory. Not
shown and not important here: each commit also has a hash of its parent
commit(s))
Debian: tarball -> .dsc -> .changes
(Tarball hashed as a whole. Not shown: tarball also directly linked to
.changes.)
Verification would then be:
- check PGP signature on tag object
- check that the commit object has the hash listed in the tag object
- unpack source package tarball(s) (since you don't yet know they're the
right ones, you need to trust the tool you do this with to not be
vulnerable to malicious content, and be prepared to reject an
overly-large tarball as a DoS attack)
- create tree hashes ('git init' in the top level of the source package
is probably the easiest way to do this)
- check that the top-level tree object has the hash listed in the commit
object
[0] https://git-scm.com/book/en/v2/Git-Internals-Git-References
Re: tag2upload (git-debpush) service architecture - draft
On Aug 02, Sam Hartman wrote: > In effect, ftpmaster is saying they are uncomfortable trusting > tag2upload very much. A simple solution to this concern would be for ftpmaster to take over the operations of tag2upload once it will be ready. -- ciao, Marco signature.asc Description: PGP signature
patent act reintroduced just in july can affet open source
hi sorry for that but seems this are very important! https://www.fsf.org/blogs/community/strengthen-free-software-by-telling-congress-to-reject-the-stronger-patents-act in 2017 was the first try.. now in july was reintroduced! all of our software are just implementing "draft"'s of the standars??? Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Bug#933766: ITP: roct-thunk-interface -- HSA Kernel Mode Thunk library for AMD KFD support
Package: wnpp Severity: wishlist Owner: Timo Aaltonen * Package name: roct-thunk-interface Version : 2.6.0 Upstream Author : Advanced Micro Devices, Inc. * URL : https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface * License : MIT Programming Lang: C Description : HSA Kernel Mode Thunk library for AMD KFD support HSA Kernel Mode Thunk library contains the user-mode API interfaces used to interact with the ROCk driver. This is part or ROCm - Open Source Platform for HPC and Ultrascale GPU Computing .
Bug#933768: ITP: golang-github-anacrolix-ffprobe-dev -- Go ffprobe wrapper
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: golang-github-anacrolix-ffprobe-dev Version : 1.0.0 Upstream Author : Matt Joiner * URL : https://github.com/anacrolix/ffprobe * License : Mozilla Public License 2.0 Programming Lang: Go Description : Go ffprobe wrapper Go ffprobe wrapper Required by github.com/anacrolix/dms, which provides a UPnP DLNA Digital Media Server used by the latest versions of rclone. To be maintained by the Go Packaging Team.
