Re: SONAME bumps (transitions) always via experimental

[Sam Hartman]

> "Graham" == Graham Inggs  writes:

Graham> Hi All
Graham> On Fri, 6 Jan 2023 at 00:33, Bastian Blank  wrote:

Graham> Would it be a bad thing to require all uploads that need to
Graham> go through NEW (source and binary) to target experimental?

Graham> I have been doing this for my own, and sponsored, uploads
Graham> for some years already.

Yes.  I think Simon and Paul covered this adequately.
The biggest concern is cases where something is already in experimental
and something comes up for the version in unstable.

The only problem with your message is *require*.
I think what Paul, Simon and apparently I are asking for is that
maintainers be able to explain why they are sending an upload that needs
to go through new to unstable in the changelog and have ftpmaster
consider whether their reason is good.

Also, I'm less convinced there's a good reason for source new uploads to
target experimental.
If it's a new package with entirely new binary packages, it shouldn't be
involved in any transitions.

So, I think what we're asking for is a change to process-new to flag
 binary-new not targeted at experimental and ask for confirmation that
 the justification in the changelog appears reasonable.
 

Bug#1028366: ITP: asmtools-java -- Java library for the production of proper and improper Java '.class' files

[Vladimir Petko]

Package: wnpp
Severity: wishlist
Owner: Debian Java team 
X-Debbugs-Cc: debian-devel@lists.debian.org,
pkg-java-maintain...@lists.alioth.debian.org

* Package name: libasmtools-java
  Version : 7.0-b09
  Upstream Author : Leonid Kuskov and others
* URL : https://github.com/openjdk/asmtools
* License : GPL-2.0
  Programming Lang: Java
  Description : Java library for the production of proper and improper Java
'.class' files

The AsmTools open source project is used to develop tools for the production of
proper and improper Java '.class' files. AsmTools are being opened in order to
facilitate a community of Java .class file production for various testing and
other OpenJDK development applications.

AsmTools consist of a set of (Java class file) assembler/disassemblers:
 - Jasm/Jdis - an assembler language that provides a Java-like declaration of
member signatures, while providing Java VM specification compliant mnemonics
for byte-code instructions. Jasm also provides high-level syntax for constructs
often found within classfile attributes. Jasm encoded tests are useful for
sequencing byte codes in a way that Javac compiled code might not normally
sequence byte-codes.
 - JCod/JDec - an assembler language that provides byte-code containers of
class-file constructs. JCod encoded tests are useful for testing the well-
formedness of class-files, as well as creating collections within a class-file
construct that might be size-bounded by a normal Java compiler. - JCod can also
be used to 'fuzz' class files in a methodical way that respects class-file
constructs.

AsmTools are completely reflexive - Java binary (.class) files may be
disassembled into textual representations, which in turn can be assembled back
to the same binary file.

AsmTools are developed to support the latest class file formats, in lock-step
with JDK development.

Other open source Java assembler tools and binary classfile frameworks exist.
They can be used for the purpose of synthesizing classfiles, however:
 - they typically are designed to enforce the limits imposed by the VM
specification of the class file format. They are not designed to produce
classes that violate those limits.
 - other assembler tools may not necessarily follow strict Java mnemonics as
defined in the Java VM spec.
 - other assembler tools may not stay in lock-step with the current generation
of the JDK and VM specifications.
 - class file libraries are harder to use for simple manipulations of any given
class file. Typically, one has to create a program in that framework to parse
and modify a class for a specific change to a given class.

The AsmTools open source project is part of the Code Tools Project. It exists
to promote a community that will improve it, further its development, and use
it to develop test suites. We encourage you to browse, download, contribute,
and get involved.

This package is required to run a number of OpenJDK hotspot tests which
currently fail.

The package will be team-maintained in the Debian Java team.

The repository with a packaging draft is available on salsa[1].

[1] https://salsa.debian.org/vpa1977/libasmtools-java

Bug#1028365: ITP: python-covdefaults -- coverage plugin to provide sensible default settings

[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: python-covdefaults
  Version : 2.2.2
  Upstream Contact: Anthony Sottile 
* URL : https://github.com/asottile/covdefaults
* License : MIT/expat
  Programming Lang: Python
  Description : coverage plugin to provide sensible default settings

Bug#1028342: ITP: lingua-franca -- Mycroft's multilingual text parsing and formatting library.

[Scarlett Moore]

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

* Package name: lingua-franca
  Version : 0.4.2
  Upstream Author : MycroftAI Developers 
* URL : https://github.com/MycroftAI/lingua-franca
* License : Apache License 2.0
  Programming Lang: Python
  Description : Mycroft's multilingual text parsing and formatting library.

 A framework that is adopted as the common language between speakers
 with different native tongues.

 This package is a dependency of mycroft-core.
 This package will be maintained by the MycroftAI team.

Bug#1028341: ITP: libtest2-tools-command-perl -- test simple unix commands

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Perl Group 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libtest2-tools-command-perl
  Version : 0.20
  Upstream Contact: Jeremy Mates 
* URL : https://metacpan.org/release/Test2-Tools-Command
* License : BSD-3-clause
  Programming Lang: Perl
  Description : test simple unix commands

 Test2::Tools::Command tests
 that commands given particular arguments result in particular outputs
 by way of the exit status word, standard output, and standard error.
 Various parameters to the command function alter
 exactly how this is done,
 in addition to variables that can be set.
 .
 The commands are expected to be simple,
 for example filters that maybe accept standard input
 and respond with some but not too much output.
 Interactive or otherwise complicated commands
 will need some other module such as Expect to test them,
 as will programs that generate too much output.

This package is needed for upcoming releases of licensecheck.
It will be maintained in the Perl team, at


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmO8VFgACgkQLHwxRsGg
ASFAzA//f4C6+3luhrVe3yd9UFbYbuCa2I3AeSrrBLjaZqSCt1JA2rGF0VganxCR
fFobR+2tdZuvdX9MltV/p/93lzhBgkIu/HRU9bOUta2blQMiZwx0sij//SICaWe9
UVEuxo+mVEHtDV3BPSnZ1L1EnRJwUqwf5R6oLgHQpUB8WlR1uhCsiXtctJ8VcRHU
hMijLwoJvf8G81qPbyjz15x0g3HdWggwPDPqQCOeXZ+zIwPeh8Y9D7VXtninCpu2
OHVXhXagQDMhErDnS6DHCKlrzIKLXAY7yD/VCOCpXIbv4OgXHC4jwnc7nYXM2ZCp
Seee50DnVob1uilLSiKhd0L9j+t34ADqK2HYBXwKbPQWahFj5/vQpKo4FleWyxNW
C0wRTq6RAvP0wkFrB5sJPBkjcZXQhJU8l5lb7l2f/24RN4v0clEoLahy2Z8mJ/ng
GOJEKl4p5gVrHh7tVlC5DsiQIlBVd72cA/xfm4JaN/b8+C75/ibP/4zSV+hOOLdm
a3oGpiJZT6R41pdmuVpNbyzWzPHBUpAIHZafZ0WXBpqaCtCZSlI0rP925CqLpSsi
erGx24+882835eZ19KFAyxtBfmxHXF08ePi+Bb9ex2jRcJpnBID3ZFT/kxYUPMBH
vujbMn2UdE6YDJktpnkm3LkAmhJegRl36iyx48l/hkPWbgqV7M0=
=y8F6
-END PGP SIGNATURE-

Re: Should singularity-container make it to next release?

[Andreas Tille]

Hi,

it would be great if someone from Security Team might raise some
opinion to this question.

Kind regards
Andreas.

Am Mon, Jan 09, 2023 at 03:51:10PM +0530 schrieb Nilesh Patra:
> Hi,
> 
> On Wed, Oct 12, 2022 at 09:38:27PM +0530, Nilesh Patra wrote:
> > src:singularity-container was lying around in a bad shape for several years
> > and had missed 2 debian releases until me and Andreas picked it up again.
> > It is currently in a reasonably good condition. I was excited to have it in
> > stable release again, but I have a couple of doubts over it.
> > 
> > 1. A little background:
> > singularity-container sync the code from the upstream codebase for sylabs[1]
> > and there also exists a community-maintained fork called apptainer.
> > Sylabs singularity CE seems to sync up a lot of code with apptainer in
> > many releases. The apptainer community announcement page about the split 
> > also
> > hints towards saying similar stuff, but this is all the more confusing as 
> > it is
> > hard to draw a line b/w them.
> > A while back, I found a reddit comment[4] from the current maintainer of 
> > sylabs
> > singularity which has a statement:
> > 
> > | At this point there it appears that Apptainer 1.0 will be very close
> > | to SingularityCE 3.9 which we released recently, given
> > | the picks from SingularityCE into the code base.
> > 
> > So I am absolutely confused if it makes sense to package apptainer at all or
> > should I just let it be?
> > 
> > 2. The _more_ important question:
> > There are CVEs being discovered in singularity-container -- no biggie. 
> > However, some
> > of the CVE fixes are simply _hidden_ from the user view.
> > As a concrete example, there was
> > a "CVE-2021-33622" opened[5] against singularity-CE, and the only 
> > information
> > upstream provides is that it has been fixed in the 3.7.x of the community 
> > edition
> > but there is no information about _what_ the fix was.
> > I tried asking upstream about this but did not get a pin-pointed reply[6] 
> > and it
> > appears that upstream is somewhat discrete about these.
> > 
> > A similar bug has been fixed in the latest release, CVE-2022-39237 here[7] 
> > but it
> > does not say _what_ patch fixes it exactly.
> > And the problem is that apptainer has addressed the exact same bug in
> > its latest release and they too are un-clear about it[8].
> > 
> > So my fear is that: Once singularity-container hits stable release, and 
> > there is
> > a CVE being found. It'd be a hellhole for me/others to find what exactly
> > fixed the CVE (unless it is being clearly stated), and apply that. The only
> > option left would be to upgrade the package to fix the CVE and I don't know 
> > if
> > release team would allow that.
> > 
> > And I don't see this problem getting fixed with apptainer as well, since 
> > there
> > are bugs that both the codebases would keep on inheriting from one another.
> > And thus I am not sure if this situation is OK for stable release or not.
> > 
> > OTOH, singularity is an important package and many users would be happy to 
> > have
> > it in stable -- I have even got a couple of bug reports/texts saying
> > people are happy to see a new update of singularity.
> 
> I started this thread a while back, and decided to simply ask upstream about 
> what their
> opinion is[9]
> It looks like the situation still not fully certain on whether to let 
> singularity make it to stable
> or not.
> 
> I'd appreciate if someone on the list could chime in and give an opinion on 
> if they
> consider it do-able or not for upcoming bookworm release.
> 
> I've kept upstream in CC to avoid ping-pong, and thanks David for a nice 
> elaborate reply.
> 
> > [1]: https://github.com/sylabs/singularity
> > [2]: https://github.com/apptainer/apptainer
> > [3]: https://apptainer.org/news/community-announcement-20211130/
> > [4]: 
> > https://www.reddit.com/r/HPC/comments/r61bto/comment/hmspn72/?utm_source=share&utm_medium=web2x&context=3
> > [5]: 
> > https://support.sylabs.io/support/solutions/articles/4287130-3-5-8-security-release-cve-2021-33622-
> > [6]: https://github.com/sylabs/singularity/issues/586
> > [7]: https://github.com/sylabs/sif/security/advisories/GHSA-m5m3-46gj-wch8
> > [8]: https://github.com/apptainer/apptainer/releases/tag/v1.1.2
> [9]: https://github.com/sylabs/singularity/issues/1235#issuecomment-1375334909
> 
> -- 
> Best,
> Nilesh



-- 
http://fam-tille.de

Re: Should singularity-container make it to next release?

[David Trudgian]

Hi all,

> +  Security support?
>   I see upstream comments that they will disclose the relevant
> fix/commit for CVE, then it should be enough. I think most packages in

Just noting here that I've added a bit more on the GitHub thread r.e.
exactly what form fixes are available in with respect to the lifecycle
of SingularityCE versions.

TLDR...

* We only do patch releases for a minor x.y version of the open-source
SingularityCE for ~6 months.

* For versions of SingularityCE that we turn into a commercial
SingularityPRO release our security policy means we will provide
diffs only for security fixes that we apply to open source code in
SingularityPRO, *and that apply* to the SingularityCE version from
which SingularityPRO was branched. It is not guaranteed that every
security issue in SingularityCE 3.9 is covered by diffs we release
based on the (closed) long term support work for SingularityPRO 3.9.
Security issues arising from older dependencies in SingularityCE would
need to be tracked separately, for example.

* Everything else will need backporting by the distro. We follow
dependency updates (including major version updates) quickly, and we
only target the latest 2 versions (upstream supported) of Go. This may
impact the ease of backporting significantly over the course of a
Debian stable release.

Cheers,

-- 
David Trudgian
Sylabs Inc.

Re: Should singularity-container make it to next release?

[Shengjing Zhu]

Hi Nilesh,

On Mon, Jan 9, 2023 at 6:21 PM Nilesh Patra  wrote:
> I started this thread a while back, and decided to simply ask upstream about 
> what their
> opinion is[9]
> It looks like the situation still not fully certain on whether to let 
> singularity make it to stable
> or not.
>
> I'd appreciate if someone on the list could chime in and give an opinion on 
> if they
> consider it do-able or not for upcoming bookworm release.
>

Could you list the concerns that you have?

+  Security support?
  I see upstream comments that they will disclose the relevant
fix/commit for CVE, then it should be enough. I think most packages in
Debian rely on the Debian maintainer to backport the fix.
+ Lacking tests? (as per upstream concerns in the Github issue)
  Do you plan to enable all the tests? I see you have disabled many tests[1]
  Or even better, could you run the integration/e2e tests with
autopkgtest? For example, you can take a look at the containerd
package that I've maintained[2].

[1] 
https://salsa.debian.org/hpc-team/singularity-container/-/blob/debian/3.10.3+ds1-1/debian/rules#L68
[2] 
https://salsa.debian.org/go-team/packages/containerd/-/blob/debian/sid/debian/tests/cri-integration

https://salsa.debian.org/go-team/packages/containerd/-/blob/debian/sid/debian/tests/integration

-- 
Shengjing Zhu

Re: Should singularity-container make it to next release?

[Nilesh Patra]

Hi,

On Wed, Oct 12, 2022 at 09:38:27PM +0530, Nilesh Patra wrote:
> src:singularity-container was lying around in a bad shape for several years
> and had missed 2 debian releases until me and Andreas picked it up again.
> It is currently in a reasonably good condition. I was excited to have it in
> stable release again, but I have a couple of doubts over it.
> 
> 1. A little background:
> singularity-container sync the code from the upstream codebase for sylabs[1]
> and there also exists a community-maintained fork called apptainer.
> Sylabs singularity CE seems to sync up a lot of code with apptainer in
> many releases. The apptainer community announcement page about the split also
> hints towards saying similar stuff, but this is all the more confusing as it 
> is
> hard to draw a line b/w them.
> A while back, I found a reddit comment[4] from the current maintainer of 
> sylabs
> singularity which has a statement:
> 
> | At this point there it appears that Apptainer 1.0 will be very close
> | to SingularityCE 3.9 which we released recently, given
> | the picks from SingularityCE into the code base.
> 
> So I am absolutely confused if it makes sense to package apptainer at all or
> should I just let it be?
> 
> 2. The _more_ important question:
> There are CVEs being discovered in singularity-container -- no biggie. 
> However, some
> of the CVE fixes are simply _hidden_ from the user view.
> As a concrete example, there was
> a "CVE-2021-33622" opened[5] against singularity-CE, and the only information
> upstream provides is that it has been fixed in the 3.7.x of the community 
> edition
> but there is no information about _what_ the fix was.
> I tried asking upstream about this but did not get a pin-pointed reply[6] and 
> it
> appears that upstream is somewhat discrete about these.
> 
> A similar bug has been fixed in the latest release, CVE-2022-39237 here[7] 
> but it
> does not say _what_ patch fixes it exactly.
> And the problem is that apptainer has addressed the exact same bug in
> its latest release and they too are un-clear about it[8].
> 
> So my fear is that: Once singularity-container hits stable release, and there 
> is
> a CVE being found. It'd be a hellhole for me/others to find what exactly
> fixed the CVE (unless it is being clearly stated), and apply that. The only
> option left would be to upgrade the package to fix the CVE and I don't know if
> release team would allow that.
> 
> And I don't see this problem getting fixed with apptainer as well, since there
> are bugs that both the codebases would keep on inheriting from one another.
> And thus I am not sure if this situation is OK for stable release or not.
> 
> OTOH, singularity is an important package and many users would be happy to 
> have
> it in stable -- I have even got a couple of bug reports/texts saying
> people are happy to see a new update of singularity.

I started this thread a while back, and decided to simply ask upstream about 
what their
opinion is[9]
It looks like the situation still not fully certain on whether to let 
singularity make it to stable
or not.

I'd appreciate if someone on the list could chime in and give an opinion on if 
they
consider it do-able or not for upcoming bookworm release.

I've kept upstream in CC to avoid ping-pong, and thanks David for a nice 
elaborate reply.

> [1]: https://github.com/sylabs/singularity
> [2]: https://github.com/apptainer/apptainer
> [3]: https://apptainer.org/news/community-announcement-20211130/
> [4]: 
> https://www.reddit.com/r/HPC/comments/r61bto/comment/hmspn72/?utm_source=share&utm_medium=web2x&context=3
> [5]: 
> https://support.sylabs.io/support/solutions/articles/4287130-3-5-8-security-release-cve-2021-33622-
> [6]: https://github.com/sylabs/singularity/issues/586
> [7]: https://github.com/sylabs/sif/security/advisories/GHSA-m5m3-46gj-wch8
> [8]: https://github.com/apptainer/apptainer/releases/tag/v1.1.2
[9]: https://github.com/sylabs/singularity/issues/1235#issuecomment-1375334909

-- 
Best,
Nilesh


signature.asc
Description: PGP signature