Re: About lintian

[Felix Lechner]

Dear Norbert,

On Sun, Jan 17, 2021 at 5:02 AM Norbert Preining  wrote:
>
> you said you have plans to set up a test version of the Lintian web
> application on non-Debian infrastructure. How is that going, Felix?

A beta version of Lintian's new service is now live at
lintian.debian.*net*. [1] The Node-based web app is backed by 90 GB of
PostgreSQL data. I used connection pools, but the site will load
slowly until I get more memory. Please be patient—I hope it is worth
your while. The pages are superior to what we had previously because
they show your override comments. The code base can also be expanded
more easily.

For any issues or suggestions please find instructions in the page
footers. I am still adding features, however, and only replied because
of the upcoming release. Please star(*) our repository [2] on Salsa if
you like it. Thanks!

Please have a good weekend!

Kind regards
Felix Lechner

[1] https://lintian.debian.net/
[2] https://salsa.debian.org/lintian/detagtive

Processed: reassign 986292 to command-not-found

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 986292 command-not-found
Bug #986292 [general] general: sqlite3 problem when a command is not available
Bug reassigned from package 'general' to 'command-not-found'.
Ignoring request to alter found versions of bug #986292 to the same values 
previously set
Ignoring request to alter fixed versions of bug #986292 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
986292: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986292
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#986295: ITP: r-bioc-ballgown -- Flexible, isoform-level differential expression analysis

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org

* Package name: r-bioc-ballgown
  Version : 2.22.0+dfsg
  Upstream Author : Jack Fu 
* URL : https://bioconductor.org/packages/ballgown
* License : Artistic-2.0
  Programming Lang: R
  Description : Flexible, isoform-level differential expression analysis
  Tools for statistical analysis of assembled transcriptomes,
  including flexible differential expression analysis, visualization of
  transcript structures, and matching of assembled transcripts to annotation.
  
  I shall maintain this package

Bug#986292: general: sqlite3 problem when a command is not available

[m]

Package: general
Severity: normal
X-Debbugs-Cc: noadr...@hotmail.com

Everytime a command is not available, this comes up.


command-not-found version: 0.3
Python version: 3.9.1 final 0
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2021.1
Codename:   kali-rolling
Exception information:

unable to open database file
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 90, in main
cnf = CommandNotFound.CommandNotFound(options.data_dir)
  File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", line 
79, in __init__
self.db = SqliteDatabase(dbpath)
  File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in 
__init__
self.con = sqlite3.connect(filename)
sqlite3.OperationalError: unable to open database file

Bug#986288: ITP: poke -- GNU poke, an interactive, extensible binary editor

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: poke
  Version : 1.1
  Upstream Author : Jose E. Marchesi
* URL or Web page : https://www.jemarch.net/poke
* License : GPL-3+
  Description : GNU poke, an interactive, extensible binary editor

Re: Questioning debian/upstream/signing-key.asc

[Guillem Jover]

[ CCing Daniel. ]

On Fri, 2021-03-26 at 17:31:16 +0100, Ansgar wrote:
> On Fri, 2021-03-26 at 09:06 -0700, Russ Allbery wrote:
> > I'm not all that familiar with the intended semantics of OpenPGP key
> > expirations, but intuitively I think a signature made before the
> > expiration should be considered valid, even if the key has now
> > expired and thus shouldn't be used to make new signatures.
> 
> How would you know that the signature was made before the key expired?

Ideally, because our tooling would not let such signatures through
into the archive, so we'd be able to tell automatically whether this
would hold at least at upload time.

(If the certificate would have expired at that time, I'd expect the
Debian maintainer to talk with the upstream maintainer about this.)

> Other systems (e.g. signed executables on Windows) have a trusted third
> party sign the timestamp for that, but OpenPGP doesn't do so.

If we are not going to trust the upstream signed signature timestamp,
then that seems it should be the least of our worries then? I don't
see why we'd trust the code upstream has provided?

Thanks,
Guillem

Re: Questioning debian/upstream/signing-key.asc

[Guillem Jover]

Hi!

[ Ccing Daniel, as he proposed the shipping of upstream signatures, so
  leaving full context. ]

On Fri, 2021-03-26 at 10:13:25 +0100, Christoph Biedl wrote:
> a few days ago, I ran uscan on a package where I knew there was a new
> upstream version - just to encounter an validation error since the
> keys in debian/upstream/signing-key.asc had expired.
> 
> After that, things escalated a little, and eventually I wrote a script
> that downloads d/u/s-k for each source package and examines the
> expiration status. And I ended up with:
> 
> 
>   maincontrib
> 
> Total number of   32761161
> source packages
> 
> Source packages that   2157  8
> ship d/u/s-k
> 
> Of those:
> 
> Failed to parse the file  3  0
> 
> Some keys have expired  306  1
> 
> All keys have expired   469  2
> 
> 
> Another about 40 distinct keys will expire within the next three months.
> 
> So for more than 20 percent of the packages with d/u/s-k, it's
> impossible to verify a new upstream tarball without extra work. Ouch.

I don't think that there was ever any expectation that such signing
certificates would be usable for any future releases though? As these
do not take into account new release maintainers, and changed, revoked
or expired certificates.

> Of course I understand there are various reasons why this happens, and
> several are not the maintainer's fault. But at least in some cases it's
> obvious the maintainers didn't care: When there has been an upload with
> a new upstream version released after the expiration. This has
> happened, hopefully they've verified the tarball by other means.

That's IMO a tooling problem. For example dpkg-source didn't use to
verify these at build time in the past so that's an obvious place this
would be let through unnoticed. Even now it just only warns, which can
be easy to miss. Also I guess people might not always use uscan to
fetch the tarballs.

> So, how to go from here?

Daniel and I happened to discuss issues related to this several days
ago, and we summarized this in
.

> The obvious thing to do now was a mass bug filing, and I might
> do that.

I'm not sure that's helpful though? I think instead making our tooling
more strict would be. Stuff like making sure uscan, dpkg-source,
lintian, dupload/dput/dput-ng or even dak error out on these, would
avoid the problem at creation or upload time.

Filing bugs about this seems it would be similar to filing bugs about
signing problems with .dsc IMO.

> However, I uncertain whether is really worth the efforts to maintain
> d/u/s-k, or more precisely, ping maintainers to do so. Personally, I
> really like it when uscan also validates signatures. But it seems that
> enthusiasm isn't quite shared among all contributors.

I do think the upstream signatures make sense, as they provide a
provenance chain from Debian, which is helpful f.ex. in case upstream
disappears or the tarballs upstream get modified, or simply to quickly
check whether it was created by an upstream developer.

But this might require more work, as has been mentioned in the thread,
this needs checking what is the state of the signing certificates at
the current time and at the signing time, and the relation of the
owner of that certificate at those times.

In any case the security properties of the upstream tarball signatures
and .dsc/.changes/.buildinfo apply mainly in the path from the upstream
to Debian maintainer up to the Debian archive, where this transitions
to the signatures made by the archive which do support resigning and
automatic key rotation for example.

> PS: Those who want to argue lintian should for check for such expired
> key, I couldn't agree more. Please read the discussion in #985793 first.

Thanks,
Guillem