Bug#1054537: Squid 6.3: multiple vulnerabilities, patches available
Package: squid Version: 6.3-1 Severity: grave Tags: security patch X-Debbugs-Cc: Debian Security Team Hi, https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2023-2725 links to a bunch of squid advisories, three of which have CVSS scores of 9+: https://github.com/squid-cache/squid/security/advisories/GHSA-2g3c-pg7q-g59w https://github.com/squid-cache/squid/security/advisories/GHSA-phqj-m8gv-cq4g https://github.com/squid-cache/squid/security/advisories/GHSA-543m-w2m2-g255 https://github.com/squid-cache/squid/security/advisories/GHSA-j83v-w3p4-5cqh Squid 6.4 includes the fix; patches for 6.3 are provided, but don't apply cleanly to the Debian sources. Please package a non-vulnerable version ASAP. Thanks! András -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (350, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled -- Computers are not intelligent. They only think they are.
Bug#1031295: pcp fails to install without systemd
Hi, it seems to me that in postinst, instead of if $do_systemd then systemctl start pmcd.service >/dev/null systemctl start pmlogger.service >/dev/null elif which invoke-rc.d >/dev/null 2>&1 then invoke-rc.d pmcd start invoke-rc.d pmlogger start else /etc/init.d/pmcd start /etc/init.d/pmlogger start fi You could just do service pmcd start service pmlogger start Additionally, I think a case can be made for ignoring failures to start these services in postinst. If the package fails to configure, that'll break unattended-upgrades which will then also not install security updates. András -- A hangover: the wrath of grapes.
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, Mar 02, 2020 at 01:45:26PM -0500, Marvin Renich wrote: Hi, > I don't have a github account, and do not wish to get one for this. > Will someone (Debian maintainer for neomutt, or someone else interested > in this bug) please file this with upstream as a separate bug, pointing > out that the other github issue is not the same as this bug, even though > some of the same code may be involved. I filed https://github.com/neomutt/neomutt/issues/2161. Best regards, András -- Microsoft follows standards the same way fish follow migrating caribou.
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, Mar 02, 2020 at 03:18:54PM +0100, Andreas Henriksson wrote: > > Your rationale for downgrading the severity of an issue like this is that it > > doesn't bother you personally? > > My rationale, if you must know, is that if this is an important issue, > then the people who consider it an important issue will ofcourse work on > getting it fixed. I'm curious -- what exactly do you have in mind? How should the users bothered by this bug "work on it"? What would you consider a reasonable, acceptable level of effort? > There's nothing in debian policy (the document who defines the severity > levels for the bug tracking system) that says 'If you raise the severity > of a bug report then "someone else" has to do the work for you'. Nobody "has" to "do the work". It's just that if the work is not done, the issue stays open. If it meets the definition of a "grave" bug, then it stays grave. You're right in that if it's important enough for *the right people*, then it'll get fixed eventually. It's entirely possible that the the users affected by a bug are not the right ones to effect a fix. You can argue with the severity, but I don't think you should downgrade it for frivolous reasons like "I'm not interested in fixing it", or "I don't like the attitude of a commenter; I think they're being lazy." > Scratch your own itch. Sorry, no, that's not how this works. I'll scratch my own itch if/when I can, and also the itches of others if/when I can. This is not a bug I can realistically fix, but that doesn't affect either its severity or its existence. You don't get to downgrade a bug that meets the criteria for being "grave" just because you aren't personally affected by it, or because the user who reported it (or someone who commented on it) is unable or unwilling to fix it himself/herself. I'm sure you don't need me to tell you that. > The previously provided suggestion that this might lead to data loss is > a bit far fetched if you ask me. That's a valid argument. FWIW, I have no opinion. I filed the bug with a normal priority and won't insist on it being grave. If you think you can downgrade it for the right reasons, go ahead (as far as I'm concerned). Best regards, András -- Get married and share the problems you didn't know you had.
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, Mar 02, 2020 at 02:22:44PM +0100, Andreas Henriksson wrote: Hi, > > when mutt prompts for something (e.g. To: address, Subject etc.) it > > previously was possible to just keep pressing backspace until whatever > > default text was there disappeared. > > > > As of this version, it's possible to keep erasing back beyond the first > > character of the string; > [...] > > On Fri, Feb 14, 2020 at 11:31:53AM -0500, Marvin Renich wrote: > > Control: -1 severity grave > > > > I'm increasing the severity of this bug, as it can cause unintended > [...] > > I just NMUed a new upstream version of neomutt, 20191207+dfsg.1-1, > which fixes the two other outstanding RC bugs. > It seems I can still reproduce this issue however (with the first prompt > I get which is the imap password prompt for me). > > This seems somewhat like a possible UX design fail. This is done > upstream and not in debian. Do you know if there's already been any > discussion regarding this upstream? If not could you please file an > upstream bug report about this? https://github.com/neomutt/neomutt/issues/2002 > The behaviour hasn't really bothered me and I probably wouldn't even > have noticed it if it wasn't for this bug showing up on the RC bug radar > while doing my NMU, so I'm quite tempted to downgrade severity again. Your rationale for downgrading the severity of an issue like this is that it doesn't bother you personally? Best regards, András -- My wife said I needed to grow up. I was speechless. It's hard to say anything when you have 45 gummy bears in your mouth.
Bug#930869: Please keep pm-utils
Hi, I just stumbled on this bugreport. I'm a happy pm-utils user and would like the package to stick around. I use it on dozens of computers ranging from servers to desktops to laptops. >From reading the bugreport, there doesn't appear to be any identifiable, specific, actionable reason for removing it, does there? Thanks! András -- Days since last off-by-one incident: -1
Bug#923957: /lib/runit/run_sysv_scripts shouldn't use 'sh -e'
Package: runit-init Version: 2.1.2-22 Severity: critical Hi, The supplied "/etc/runit/1" calls "/lib/runit/run_sysv_scripts /etc/rcS.d" during boot. /lib/runit/run_sysv_scripts runs under "sh -eu", which has the effect that if any initscript exits unsuccesfully, all subsequent scripts are skipped. This can lead to, for example, the "networking" initscript not being started, which then results in no connectivity for the box and thus no way to log in remotely. (This is my justification for the 'critical' severity: "breaks the entire system".) I think runit-init should do what /etc/init.d/rc does: log failures and continue. Thanks, András -- It's not enough to have no opinion. You must also be unable to express it.
Bug#920977: Breaks loading of db backends in Trac
On Sat, Feb 02, 2019 at 11:00:30AM +0100, Julien Cristau wrote:
Hi,
> > as long as mercurial-common is installed, the postgres and sqlite db
> > backend driver of Trac won't load:
> >
> > 2019-01-31 08:58:49,372 Trac[loader] ERROR: Skipping "trac.db.postgres =
> > trac.db.postgres_backend":
> > Traceback (most recent call last):
> > File "/usr/lib/python2.7/dist-packages/trac/loader.py", line 77, in
> > _load_eggs
> > entry.load(require=True)
> > File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
> > 2346, in load
> > return self.resolve()
> > File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
> > 2352, in resolve
> > module = __import__(self.module_name, fromlist=['__name__'], level=0)
> > File
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line
> > 172, in _demandimport
> > return _hgextimport(_origimport, name, globals, locals, fromlist, level)
> > File
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line
> > 43, in _hgextimport
> > return importfunc(name, globals, *args, **kwargs)
> > File "/usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py", line
> > 46, in
> > psycopg2_version = get_pkginfo(psycopg).get('version',
> > File "/usr/lib/python2.7/dist-packages/trac/util/__init__.py", line 806,
> > in get_pkginfo
> > metadata = 'METADATA' if dist.has_metadata('METADATA') else 'PKG-INFO'
> > File
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line
> > 151, in __getattr__
> > return getattr(self._module, attr)
> > AttributeError: 'module' object has no attribute 'has_metadata'
> > 2019-01-31 08:58:49,372 Trac[loader] DEBUG: Loading plugin "trac.db.sqlite"
> > from "/usr/lib/python2.7/dist-packages"
> > 2019-01-31 08:58:49,374 Trac[loader] ERROR: Skipping "trac.db.sqlite =
> > trac.db.sqlite_backend":
> > Traceback (most recent call last):
> > File "/usr/lib/python2.7/dist-packages/trac/loader.py", line 77, in
> > _load_eggs
> > entry.load(require=True)
> > File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
> > 2346, in load
> > return self.resolve()
> > File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
> > 2352, in resolve
> > module = __import__(self.module_name, fromlist=['__name__'], level=0)
> > File
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line
> > 172, in _demandimport
> > return _hgextimport(_origimport, name, globals, locals, fromlist, level)
> > File
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line
> > 43, in _hgextimport
> > return importfunc(name, globals, *args, **kwargs)
> > File "/usr/lib/python2.7/dist-packages/trac/db/sqlite_backend.py", line
> > 45, in
> > pysqlite_version_string = get_pkginfo(sqlite).get('version',
> > File "/usr/lib/python2.7/dist-packages/trac/util/__init__.py", line 806,
> > in get_pkginfo
> > metadata = 'METADATA' if dist.has_metadata('METADATA') else 'PKG-INFO'
> > File
> > "/usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py", line
> > 151, in __getattr__
> > return getattr(self._module, attr)
> > AttributeError: 'module' object has no attribute 'has_metadata'
> >
> > I don't understand what the connection is, but removing mercurial-common
> > (which ships
> > /usr/lib/python2.7/dist-packages/hgdemandimport/demandimportpy2.py) helps.
> >
> As far as I can tell for this to happen something must have called
> hgdemandimport.enable(). Can you track down what that is?
I'm afraid not; not only do I have almost no idea how, I also lack the time
to do it in the short term.
András
--
Politics: Poly = many, Tics = Blood sucking parasites.
