debian/copyright format and SPDX

[Hideki Yamane]

 tl;dr: How about considering updating debian/copyright format to have
more compatibility with SPDX format


 SBOM is expected to be used widely and several tools support it as a trend
 now, since US government asks to use it. There are two formats for it,
 Software Package Data Exchange (SPDX) and CycloneDX.

 SPDX is led by the Linux foundation project, OpenChain for license
 compliance. And CycloneDX is developed by the Open Web Application Security
 Project (OWASP), so it is intended to use track vulnerabilities, IMO.


 Well, as I said above, several tools support SPDX and CycloneDX now and
 continue to be expanded, so I consider it'd be better if debian/copyright
 has more compatibilities with them, especially SPDX. It would be easier
 to handle debian/copyright data with tools that are outside of Debian.


 Making appropriate debian/copyright file is hard and boring task, IMHO,
 but if non-Debian people also can help it, it would be easier to fix it.


 Any ideas?


-- 
Hideki Yamane 

Re: debian/copyright format and SPDX

[Jonas Smedegaard]

Hi Hideki,

Quoting Hideki Yamane (2023-09-08 08:39:09)
½> 
>  tl;dr: How about considering updating debian/copyright format to have
> more compatibility with SPDX format
> 
> 
>  SBOM is expected to be used widely and several tools support it as a trend
>  now, since US government asks to use it. There are two formats for it,
>  Software Package Data Exchange (SPDX) and CycloneDX.
> 
>  SPDX is led by the Linux foundation project, OpenChain for license
>  compliance. And CycloneDX is developed by the Open Web Application Security
>  Project (OWASP), so it is intended to use track vulnerabilities, IMO.
> 
> 
>  Well, as I said above, several tools support SPDX and CycloneDX now and
>  continue to be expanded, so I consider it'd be better if debian/copyright
>  has more compatibilities with them, especially SPDX. It would be easier
>  to handle debian/copyright data with tools that are outside of Debian.
> 
> 
>  Making appropriate debian/copyright file is hard and boring task, IMHO,
>  but if non-Debian people also can help it, it would be easier to fix it.

Only issue I am aware of is that SPDX shortname "MIT" equals Debian
shortname "Expat".  It sounds like you are referring to more and larger
incompatibilities than that.  Do you mean e.g. support for checksums of
files (which will blow up size and kill readability of the file)?

Perhaps as a start compile a list of incompatibilities on a wiki page -
or point to it if one already exists.  Then we can add pros and cons at
that page, as the discussion here progresses.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: debian/copyright format and SPDX

[Jeremy Stanley]

On 2023-09-08 12:09:09 +0530 (+0530), Hideki Yamane wrote:
[...]
>  SPDX is led by the Linux foundation project, OpenChain for license
>  compliance.
[...]

Unless I'm misreading, OpenChain follows the REUSE specification
which acknowledges the sufficiency of "DEP5" formatted license info:

https://github.com/OpenChain-Project/Reference-Material/blob/master/General-Compliance-Support-Material/REUSE.software/en/REUSE.software-3.0.md

Since Debian's machine-readable format has been around longer than
either of the newer formats you mentioned, it seems like it would
make more sense for the tools to incorporate a parser for it rather
than create needless churn in the package archive just to transform
an established standard into whatever the format-du-jour happens to
be (and then halfway through another new format gains popularity,
and the process starts all over again).

Sorry to come across as skeptical, but there are organizations out
there churning out redundant "standards" rather than reusing
suitable existing formats, and while I'd like to assume that it's
simply because they did insufficient research to be aware of prior
art, it seems like all too often it's in pursuit of signing on more
and more donors at the expense of distracting active free/libre open
source software communities from what they would normally focus on
achieving.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Bug#1051482: ITP: slowloris -- Security testing tool for web servers

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: slowloris
  Version : 0.14.2
  Upstream Contact: Gokberk Yaltirakli 
* URL : https://github.com/gkbrk/slowloris
* License : MIT/Expat
  Programming Lang: Python
  Description : Security testing tool for web servers

Open source tool used to perform Denial of Service (DoS) attacks on web
 servers. Slowloris exploits a vulnerability in web servers called “Keep-Alive”
 to exhaust server resources and make them inaccessible.
 .
 Slowloris offers a number of configurable options, allowing fine-grained
 control over request behavior. Some of which include:
  - Web Server Port: It is possible to specify the web server port to be
the target of the action, usually port 80.
  - Number of Sockets: You can determine the number of simultaneous sockets
that the tool will use to send requests to the server.
  - Log Increase (Verbose): The level of detail of the information logged
during the run can be adjusted, allowing a more detailed analysis of the
results.
  - User agent randomization: Slowloris can randomize user agents on each
request, making it difficult to detect the destination server.
  - Use of SOCKS5 proxy: The tool supports the use of a SOCKS5 proxy to further
hide the source of requests.
  - Use of HTTPS for Requests: In addition, it is possible to configure the
tool to use the HTTPS protocol for requests, adding another layer of
obscurity.
  - Time interval between headers: You can specify a time interval between
sending request headers, controlling the rate of requests.

Re: debian/copyright format and SPDX

[Russ Allbery]

Jeremy Stanley  writes:

> Since Debian's machine-readable format has been around longer than
> either of the newer formats you mentioned, it seems like it would make
> more sense for the tools to incorporate a parser for it rather than
> create needless churn in the package archive just to transform an
> established standard into whatever the format-du-jour happens to be (and
> then halfway through another new format gains popularity, and the
> process starts all over again).

I don't think the file format is the most interesting part of SPDX.  They
don't really have a competing format equivalent to the functionality of
our copyright files (at least that I've seen; I vaguely follow their
lists).  Last time I looked, they were doing a lot with XML, which I don't
think anyone would adopt for new formats these days.  (YAML or TOML or
something like that is now a lot more popular.)  In terms of file formats,
writing a lossy converter from Debian copyright files to whatever format
is of interest for BOMs would probably do most of the job.

The really interesting part of SPDX is the license list and the canonical
name assignment, which is *way* more active and *way* more mature at this
point than the equivalent in Debian.  They have a much larger license
list, which is currently being bolstered by Fedora, and the new licenses
and rules for deduplicating them are reviewed by lawyers as part of their
maintenance process.  Their identifiers are also incerasingly used in
upstream software in SPDX-License-Identifier pseudo-headers.

I have no idea how to do a transition, but I do think Debian would benefit
from adopting the SPDX license identifiers where one exists, and possibly
from joining forces with Fedora to submit and get idenifiers assigned to
the licenses that we see that are not yet registered.

-- 
Russ Allbery (r...@debian.org)  

Re: debian/copyright format and SPDX

[Russ Allbery]

Jonas Smedegaard  writes:

> Only issue I am aware of is that SPDX shortname "MIT" equals Debian
> shortname "Expat".

There was also some sort of weirdly ideological argument with the FSF
about what identifiers to use for the GPL and related licenses, which
resulted in SPDX using an "-only" and "-or-later" syntax in the identifier
at the insistence of the FSF rather than a separate generic syntax the way
that we do.

https://spdx.org/licenses/ is the current license list and assigned short
identifiers.

-- 
Russ Allbery (r...@debian.org)  

Re: debian/copyright format and SPDX

[Mattia Rizzolo]

On Fri, Sep 08, 2023 at 07:34:43AM -0700, Russ Allbery wrote:
> I don't think the file format is the most interesting part of SPDX.  They
> don't really have a competing format equivalent to the functionality of
> our copyright files (at least that I've seen; I vaguely follow their
> lists).  Last time I looked, they were doing a lot with XML, which I don't
> think anyone would adopt for new formats these days.  (YAML or TOML or
> something like that is now a lot more popular.)

Formally, SPDX is only a data model, which supports several
serializations formats.  The XML one is I believe the most common one
for some technically good reasons, but it does support YAML
serialization, as well as some lossy ones as well (like CSV, plaintext,
etc...).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: debian/copyright format and SPDX

[Jeremy Stanley]

On 2023-09-08 13:31:43 + (+), Jeremy Stanley wrote:
> On 2023-09-08 12:09:09 +0530 (+0530), Hideki Yamane wrote:
> [...]
> >  SPDX is led by the Linux foundation project, OpenChain for license
> >  compliance.
> [...]
> 
> Unless I'm misreading, OpenChain follows the REUSE specification
> which acknowledges the sufficiency of "DEP5" formatted license info
[...]

Apologies for the confusion on my part. I see from the responses now
that I misunderstood the suggestion. If it's to normalize some of
the contents in copyright files in order to match SPDX identifiers
rather than adopt an entire new format, then I agree that makes a
bit more sense (though does seem like a daunting undertaking). FWIW,
there does already seem to be some attempt at alignment in the
current specification when it comes to handling things like
versioned licenses, and it refers back to the SPDX registry for
license texts.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Bug#1051500: ITP: golang-github-jesseduffield-lazycore -- Shared functionality for lazygit and lazydocker

[Jongmin Kim]

Package: wnpp
Severity: wishlist
Owner: Jongmin Kim 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-jesseduffield-lazycore
  Version : 0.0~git20221023.718a4ca
  Upstream Contact: Jesse Duffield 
* URL : https://github.com/jesseduffield/lazycore
* License : Expat
  Programming Lang: Go
  Description : Shared functionality for lazygit and lazydocker

 This package provides a shared functionality library written in Go,
 for lazygit and lazydocker.

The package is in the dependency tree of lazygit (#908894)[1,2].

[1] https://bugs.debian.org/908894
[2] https://github.com/jesseduffield/lazygit-debian/wiki/Dependency-graph

Bug#1051506: ITP: golang-github-samber-lo -- Lodash-style Go library based on Go generics

[Jongmin Kim]

Package: wnpp
Severity: wishlist
Owner: Jongmin Kim 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-samber-lo
  Version : 1.38.0
  Upstream Contact: Samuel Berthe 
* URL : https://github.com/samber/lo
* License : Expat
  Programming Lang: Go
  Description : Lodash-style Go library based on Go generics

 This package provides Lodash-style Go library based on Go generics.
 .
 The benchmarks demonstrate that generics will be much faster than
 implementations based on the "reflect" package. The benchmarks also show
 similar performance gains compared to pure "for" loops.

The package is a dependency of golang-github-jesseduffield-lazycore 
(#1051500)[1].
The package is in the dependency tree of lazygit (#908894)[2,3].

[1] https://bugs.debian.org/1051500
[2] https://bugs.debian.org/908894
[3] https://github.com/jesseduffield/lazygit-debian/wiki/Dependency-graph

Bug#1051520: ITP: python-expecttest -- expect test for python

[M. Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: python-expecttest
* URL : https://github.com/ezyang/expecttest/
* License : MIT
  Programming Lang: (python
  Description : expect test for python

Unit testing package for pytorch packages.
Will be maintained by debian deep learning team.

Thank you for using reportbug

Re: debian/copyright format and SPDX

[Hideki Yamane]

Hi,

On Fri, 08 Sep 2023 07:34:43 -0700
Russ Allbery  wrote:
> The really interesting part of SPDX is the license list and the canonical
> name assignment, which is *way* more active and *way* more mature at this
> point than the equivalent in Debian.  They have a much larger license
> list, which is currently being bolstered by Fedora, and the new licenses
> and rules for deduplicating them are reviewed by lawyers as part of their
> maintenance process.  Their identifiers are also incerasingly used in
> upstream software in SPDX-License-Identifier pseudo-headers.

 Yes, so we don't need to spare our limited resources to maintain
 license list if we adopt it, IMHO.


-- 
Hideki Yamane 

Kind invitation to join my DebConf BoF "Chatting with ftpmasters"

[Andreas Tille]

Hi ftpmasters and
developers who contributed to previous discussion with ftpmaster on this list

You might have noticed that I registered "Chatting with ftpmasters"[1]
for Debconf which is scheduled Sep 11 (Mon): 16:30  local time in Kochi
(just check the website for your local time which is printed as an
alternative).

I'd like to invite anybody who is interested to enhance the
communication to join this BoF either at site or from remote.  Locally
I'll bring some homemade sweets (quince jelly) for every member of the
ftpmaster team to thank you for all your work.

I have put my (preliminary) slides online[2] and I'm open for comments
and enhancements.  You can also add notes to etherpad[3] in advance.

Looking forward to meet you in Kochi
Andreas.

[1] https://debconf23.debconf.org/talks/31-chatting-with-ftpmasters/
[2] https://people.debian.org/~tille/talks/20230911_debconf_ftpmaster_bof/
[3] https://pad.dc23.debconf.org/p/31-chatting-with-ftpmasters

-- 
http://fam-tille.de