the autobuilders could pick up the old library on some
architectures (i.e. the library hasn't been built on that platform yet).
Really need to make sure that the library has been uploaded and built on
all platforms before you upload the dependencies.
--
Brian May
imilar situation with rust - which I also believe likes to embed code
also.
--
Brian May
security issues aren't necessarily
serious issues that warrant concern.
Any ideas, comments?
Regards
--
Brian May
https://linuxpenguins.xyz/brian/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- -
Debian LTS Advisory DLA-2550-1debian-...@lists.debian.org
https://www.debian.org/lts/security/Brian May
February 09, 2021
the code. Suspect we are not vulnerable.
CVE-2020-27845 - applied, by hand, error messages removed.
I note that this package doesn't seem to run tests on build. Which makes
me a bit nervous. It does come with tests, but so far my attempts to run
these tests have not been successful.
--
Brian May
diff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- -
Debian LTS Advisory DLA-2527-1debian-...@lists.debian.org
https://www.debian.org/lts/security/Brian May
January 18, 2021
After reading the notes for this project:
ruby-actionpack-page-caching (Brian May)
NOTE: 20200819: Upstream's patch on does not apply due to subsequent
NOTE: 20200819: refactoring. However, a quick look at the private
NOTE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- -
Debian LTS Advisory DLA-2520-1debian-...@lists.debian.org
https://www.debian.org/lts/security/Brian May
January 07, 2021
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- -
Debian LTS Advisory DLA-2485-1debian-...@lists.debian.org
https://www.debian.org/lts/security/Brian May
December 09, 2020
Brian May writes:
> I have a patch to fix this. As attached.
I believe that there are exactly two additional packages that would need
to be rebuilt in stretch (i.e. that include the http2 server code):
- dnss
- gobgpd
Not 100% sure if these support creating a http2 server, but might be
wo
tread on any toes here, by asking when I shouldn't or not asking when I
should.
--
Brian May
diff -Nru golang-golang-x-net-dev-0.0+git20161013.8b4af36+dfsg/debian/changelog golang-golang-x-net-dev-0.0+git20161013.8b4af36+dfsg/debian/changelog
--- golang-golang-x-net-dev-0.0+git20161013.8b4af36
Brian May writes:
> But golang-golang-x-net-dev is not a source package. In fact
Disregard my rumblings. I was obviously getting confused between 2
packages with similar names:
golang-golang-x-net-dev which is a source package
and:
golang-golang-x-crypto-dev which isn't a source pack
ends,Build-Depends-Indep quilt
>
> Maybe?
OK, thanks for the suggestion. This appears to work on stretch:
apt install liblz4-tool
lz4cat /var/lib/apt/lists/*Sources.lz4 | grep-dctrl -s Package -F
Build-Depends,Build-Depends-Indep quilt
--
Brian May
Brian May writes:
> Anyway, as this was marked as minor for golang-1.7 in Stretch, probably
> also should be marked as minor for golang-golang-x-net-dev also...
According to https://security-tracker.debian.org/tracker/CVE-2019-9512,
golang-golang-x-net-dev is a source package that is vuln
-Depends,Build-Depends-Indep quilt
[ no results ]
--
Brian May
https://linuxpenguins.xyz/brian/
duced later) seems correct
> to me.
I will do so.
--
Brian May
Salvatore Bonaccorso writes:
> Hi Brian,
>
> On Tue, Dec 01, 2020 at 09:01:37AM +1100, Brian May wrote:
>> I note this package - golang-github-dgrijalva-jwt-go - has been marked
>> as vulnerable to CVE-2020-26160 in both Debian stretch and buster.
>>
>> ht
to mark these versions as not vulnerable.
--
Brian May
Abhijith PA writes:
> Also my issue is cleared and jupyter-notebook *accepted* . I hope
> golang-github-ncw-rclone-dev cleared too.
Yes, the two packages of mine that were waiting now got in.
--
Brian May
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- -
Debian LTS Advisory DLA-2455-1debian-...@lists.debian.org
https://www.debian.org/lts/security/Brian May
November 19, 2020
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- -
Debian LTS Advisory DLA-2454-1debian-...@lists.debian.org
https://www.debian.org/lts/security/Brian May
November 19, 2020
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- -
Debian LTS Advisory DLA-2453-1debian-...@lists.debian.org
https://www.debian.org/lts/security/Brian May
November 17, 2020
here, please help.
I have a similar issue. I opened up a bug report:
https://bugs.debian.org/974877
I suggest you do they same. At least with the bug report there is a
formal public record of the pending request.
--
Brian May
Brian May writes:
> I have contacted ftp-master concerning rclone. Waiting a response.
Still no response. I submitted a bug report:
https://bugs.debian.org/974877
--
Brian May
e. Waiting a response.
--
Brian May
Brian May writes:
> What is the process for rebuilding these in stretch LTS? Do I need to
> add entries to dla-needed.txt and claim these entries?
I might need help here:
=== cut ===
Debian FTP Masters (28 mins. ago) ()
Subject: rclone_1.35-1+deb8u1_amd64.changes REJECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- -
Debian LTS Advisory DLA-2442-1debian-...@lists.debian.org
https://www.debian.org/lts/security/Brian May
November 10, 2020
Brian May writes:
> This produced the following output to STDOUT:
>
> === cut ===
> obfs4proxy salsa20
> packer ssh/keys
> rclone salsa20
> restic ssh/keys
> snapd salsa20
> === cut ===
snapd seems to reproduce test failures, even without my security
update
Brian May writes:
> Package: acmetool
> Package: chasquid
> Package: coyim
> Package: go-wire
> Package: gocryptfs
> Package: golang-github-azure-azure-sdk-for-go
> Package: golang-github-azure-go-autorest
> Package: golang-github-azure-go-ntlmssp
> Package: golang-git
linux-gnu/src/golang.org/x/crypto/ocsp/ocsp.go
This looks like a source file.
Wonder if it is possible to extract a list of all source files that were
used to build acmetool...
So far not getting anywhere with "readelf". But maybe "strings" might be
sufficient.
--
Brian May
mitation in the above list. It
probably won't mention, for example, packages that build depend on
golang-github-pkg-sftp-dev which depends on golang-golang-x-crypto-dev.
--
Brian May
ch ones need rebuilding? Maybe just the ones without
the 'golang-` prefix?
How do I rebuild? Do I need to upload a new version?
--
Brian May
Emilio Pozuelo Monfort writes:
> Have you checked if any rdeps need to be rebuilt?
No. I imagine there might be some. How do I check? I can't remember
right now how to check reverse build depends.
--
Brian May
I have no idea what is wrong here, or why it is fixated on a commit that
is 2 commits behind master...
--
Brian May
--- Begin Message ---
The error message was:
reference to unknown bug DLA-0001-1
reference to unknown bug DLA-0002-1
reference to unknown bug DLA-0003-1
reference to unknown bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- -
Debian LTS Advisory DLA-2402-1debian-...@lists.debian.org
https://www.debian.org/lts/security/Brian May
October 08, 2020
even without
openssh-server installed, so I think this is good to go.
--
Brian May
diff -Nru golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog
--- golang-
Utkarsh Gupta writes:
> On Mon, Oct 5, 2020 at 3:03 AM Brian May wrote:
>> I also had a look at CVE-2020-9283 (no DSA) - an invalid public key can
>> cause a panic - however I feel this is not really a security issue.
>
> But still, in case you can include a fix fo
Attached is my patch for golang-go.crypto which I intend to upload
tomorrow for:
* CVE-2019-11840
* CVE-2019-11841
I also had a look at CVE-2020-9283 (no DSA) - an invalid public key can
cause a panic - however I feel this is not really a security issue.
--
Brian May
diff -Nru golang-go.crypto
ewBuffer(b.Bytes),
b.ArmoredSignature.Body)
b.Headers has the header we need to check, but we only pass the body
b.Bytes and the signature b.ArmoredSignature.Body. As in the headers
aren't covered by the signature (I assume there is a good reason...).
Does this make sense now?
--
Brian May
ink.
I am a bit disappointed actually that the CheckDetachedSignature()
doesn't return the hash used. It means that the calling application only
has access to the insecure value that cannot be trusted.
--
Brian May
was marked as minor for golang-1.7 in Stretch, probably
also should be marked as minor for golang-golang-x-net-dev also...
--
Brian May
library.
Yes, it probably should have been two separate CVEs. Having two distinct
issues in one CVE gets confusing when only one issue gets resolved.
If I understand this correctly, I believe this part was resolved.
--
Brian May
nclude it in the message in the first place. But the fact it is
included, and it could confuse programs and/or humans if it is altered.
So the value of this header should be validated.
--
Brian May
this.
--
Brian May
diff -Nru golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog
--- golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian
Brian May writes:
> Brian May writes:
>
>> All of the distributions fail (as in the last two tests pass when they
>> should now), but bullseye at least fixes one of the failures. So it
>> looks like this was incorrectly marked as fixed (note bulleye and sid
Brian May writes:
> All of the distributions fail (as in the last two tests pass when they
> should now), but bullseye at least fixes one of the failures. So it
> looks like this was incorrectly marked as fixed (note bulleye and sid
> have the same version of this package).
I filled
Brian May writes:
> My attempts to run the reproducer program have not been successful, as
> *none* of the signatures validate. Not even the known good case.
I worked it out. The source had:
-BEGIN PGP PUBLIC KEY BLOCK-
mQENBFyeB6MBCAC+X0+7sQkrpg4zjQGj9NQSwPvDV5JjWx
buster due to certificate errors).
I was wondering if there was an error in my copy of sig_spoof. I
downloaded the source using:
https://dl.packetstormsecurity.net/1905-exploits/SA-20190513-0.txt
And deleted everything before and after the code, so I think it should
be OK.
Any ideas?
--
Brian
Roberto C. Sánchez writes:
> On Wed, Aug 12, 2020 at 08:55:43AM +1000, Brian May wrote:
>> I am seriously thinking that slirp from unstable should be ported as is
>> from sid to buster and stretch. This is not a new upstream version, it
>> has bug fixes and security u
make any security uploads to stretch?
On the other hand the security team has marked both these as no-DSA, in
buster meaning maybe I should do the same thing too?
--
Brian May
https://linuxpenguins.xyz/brian/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- -
Debian LTS Advisory DLA-2284-1debian-...@lists.debian.org
https://www.debian.org/lts/security/Brian May
July 21, 2020
aw to override or bypass
+environment restrictions to execute shell commands.
+
+ -- Brian May Thu, 16 Jul 2020 07:53:51 +1000
+
ksh (93u+20120801-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru ksh-93u+20120801/debian/patches/CVE-2019-14868.patch
ksh-93u+20120801/debian/pa
essing this segfault might be because we are attempting to access
job.freejobs[x] before job.freejobs has been initialised because we
weren't expecting to run jobs yet.
Yes, this appears to be the case:
/*
* initialize the shell
*/
Shell_t *sh_init(register int argc,register char *argv[], Shinit_f userinit)
{
[...]
env_init(shp); /* function that causes the error */
[...]
/* initialize jobs table */
job_clear();
[...]
}
--
Brian May
in ?? ()
#9 0x55db50aadb15 in ?? ()
#10 0x55db50aae3a4 in ?? ()
#11 0x55db50aefd24 in ?? ()
#12 0x55db50af106c in ?? ()
#13 0x55db50aad792 in ?? ()
#14 0x55db50ad9294 in ?? ()
#15 0x55db50abec72 in ?? ()
#16 0x55db50aa38dd in ?? ()
#17 0x00007f2658ae42e1 in __libc_start_main (main=0x55db50aa3650, argc=1,
argv=0x7ffe505157a8, init=, fini=,
rtld_fini=, stack_end=0x7ffe50515798) at ../csu/libc-start.c:291
#18 0x55db50aa368a in ?? ()
--
Brian May
000, 4096, PROT_READ) = 0
mprotect(0x7f2ccefea000, 4096, PROT_READ) = 0
munmap(0x7f2ccefe6000, 15058) = 0
brk(NULL) = 0x5633d6b5c000
brk(0x5633d6b7d000) = 0x5633d6b7d000
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
write(1, &q
check will fail, and the email will (silently) never get published.
--
Brian May
ker/commit/59a9cd9dca3afc830fea869d12baf2f3d7c21126
Should we mark it as ignored in Stretch also? Or maybe the reason (as
given in the commit message when ksh was first removed) was wrong?
https://salsa.debian.org/security-tracker-team/security-tracker/commit/b72cc677e719d37f5f3378d616d9cb53315db927
ecurity-tracker-team/security-tracker/-/commit/2e566eb8abcb548cf7020f18e4dce28aabfc5265
--
Brian May
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Package: drupal7
Version: 7.32-1+deb8u18
CVE ID : CVE-2020-13662
Drupal 7 has an Open Redirect vulnerability. For example, a user
could be tricked into visiting a specially crafted link which would
redirect them to an
unsupported packages?
--
Brian May
Brian May writes:
> Drupal7, in Jessie has 3 security issues:
My proposed changes to drupal7 in Jessie:
diff -Nru drupal7-7.32/debian/changelog drupal7-7.32/debian/changelog
--- drupal7-7.32/debian/changelog 2019-05-20 20:05:42.0 +1000
+++ drupal7-7.32/debian/changelog 2
n['path'];
+}
$options['query'] = $destination['query'];
$options['fragment'] = $destination['fragment'];
}
=== cut ===
As such, I am inclined to patch the CVE-2020-13662 / SA-CORE-2020-003
issue, but not touch the jquery issue.
Comments?
--
Brian May
https://linuxpenguins.xyz/brian/
Brian May writes:
> I sent a email to Moritz Muehlenhoff, asking why is changed it to
> unsupported, but not got a response yet.
Response was that upstream support has ended the old version unbound,
and it was deemed to risky too backport changes from supported versions
to the old v
Brian May writes:
> But... surprise surprise, it looks like buildFragment may be broken:
It looks like this commit might fix that:
https://github.com/jquery/jquery/commit/22ad8723ce07569a9b039c7901f29e86ad14523c
But this is a rather invasive commit. Don't think we should apply it to
Jes
agree with each other here :-)
--
Brian May
Holger Levsen writes:
> On Tue, Jun 09, 2020 at 07:13:03AM +1000, Brian May wrote:
>> I notice that according to DSA-4694, unbound is not supported anymore in
>> Stretch.
>> https://www.debian.org/security/2020/dsa-4694
>> Does this mean we should also mark it as u
etely different
in master:
https://github.com/jquery/jquery/blob/9c98e4e86eda857ee063bc48adbc1a11bb5506ee/src/manipulation/buildFragment.js
Will investigate further, in case there is a simple fix.
--
Brian May
Brian May writes:
> rscript = /)<[^<]*)*<\/script>/gi,
The simplest possible solution would be to update that regexp to allows
white space in the closing tag.
But of course the problem here is that a regexp isn't really the right
tool for parsing HTML content, and it i
erent file.
https://github.com/jquery/jquery/blob/d0ce00cdfa680f1f0c38460bc51ea14079ae8b07/src/core/parseHTML.js
--
Brian May
,
I would expect it to be executed.
https://snyk.io/vuln/SNYK-JS-JQUERY-569619
--
Brian May
https://linuxpenguins.xyz/brian/
I notice that according to DSA-4694, unbound is not supported anymore in
Stretch.
https://www.debian.org/security/2020/dsa-4694
Does this mean we should also mark it as unsupported in Jessie?
--
Brian May
https://linuxpenguins.xyz/brian/
or suggestions.
This sounds like a good idea to me.
Just need to come up with an appropriate list of tags to represent the
status. e.g. if a particular TODO item is waiting on response from
security team for example.
--
Brian May
ly here.
Oops. Probably obvious I mostly program in Python...
--
Brian May
skPlanner - It might
allow us to visualise the required tasks in a cleaner manner.
Also it occurred to me that Python 2 support is disappearing, but the
scripts in security tracker are still Python 3 only (my latest merge
requests have been stalled). Not sure if we need to add this to the TODO
list o
Brian May writes:
> Looking at commit
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=7d9718cfcc11eaa9d8059e721301cdc00ef8c82e,
> it looks like maybe we should be patching the attio_connected_cb()
> function instead. But this function doesn't appear to have any way
concept, not specific to hog
(which is just one protocol). See:
https://codeitbro.blogspot.com/2017/04/ble-pairing-vs-bonding.html
If you look at hog.c before the upstream commit was applied, it didn't
have any concept of bonded either.
--
Brian May
rity fix - rejecting unbonded connections -
could break stuff also.
--
Brian May
https://linuxpenguins.xyz/brian/
"Chris Lamb" writes:
> Yes I believe so. Can you go ahead and request to add it there
> whilst you have it open? If not, let me me know and I will go ahead
> with that. I have removed keystone from dla-needed.txt in 18c3371ddc.
Will do so. Probably Monday.
--
Brian May
>From dla-needed.txt:
> NOTE: 20200505: Patch for CVE-2020-11724 appears to be fairly
> invasible and, alas, no tests. (lamby)
What does invasible mean in this context?
(I think I could guess - but rather not...)
--
Brian May
https://linuxpenguins.xyz/brian/
this was a mistake, and keystone should be listed in
security-support-ended?
--
Brian May
https://linuxpenguins.xyz/brian/
t...@security.debian.org
I think, like it or not, details were already publicly available in the
referenced github issue. From comment posted on 1st March. There is
probably no point trying to keep this secret.
--
Brian May
again...
Regards
--
Brian May
https://linuxpenguins.xyz/brian/
> After consideration, the Django Security Team conclude that this is not
> a practical attack vector.
>
> Work on the related hardenings, such as the referenced tickets should
> continue.
I am inclined to think we do not need to worry about patching old
releases for this vulnerability for similar reasons.
--
Brian May
//github.com/rack/rack/commit/54600771e3c9628c873fb1140b800ebb52f18e70#diff-ec7f0fcff10d701615d85df33fbbd545
Which replaces Memcache with Dalli instead. I have no idea if Dalli has
been appropriately patched to deal with CVE-2019-16782.
--
Brian May
r as I can tell they both a the same vulnerability. Did I miss
something?
--
Brian May
d to wait a bit and see if I get any responses. If not, I
will mark this security issue as "not vulnerable" in Debian, because it
is not possible to exploit as it is broken.
--
Brian May
ch as direct lookups in the session database
using the session key?
Also I noticed - and thought interesting - that storing sessions in the
database was considered using rails (not rack being discussed here) was
deprecated in 2012)
http://blog.remarkablelabs.com/2012/12/activerecord-sessionstore-gem-extraction-rails-4-countdown-to-2013
--
Brian May
to make use of this. Or have I
> misunderstood something?
I suspect you are mostly correct.
However how many people would really notice if an attacker made numerous
connections to their website in attempt to exploit this?
--
Brian May
unclear why Rack has this issue, and not other libraries that
do a similar lookup of an untrusted key value provided by the user in
the database, e.g. Django.
--
Brian May
s the default session backend, others are also available:
https://docs.djangoproject.com/en/3.0/topics/http/sessions/#configuring-sessions
--
Brian May
e
could lead to silent breakage, which is probably not a better outcome.
--
Brian May
o pull off." - wonder if it even worth
trying to fix this for anything other then unstable+testing.
--
Brian May
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Package: ruby-rack-cors
Version: 0.2.9-1+deb8u1
CVE ID : CVE-2019-18978
This package allowed ../ directory traversal to access private resources
because resource matching did not ensure that pathnames were in a canonical
; urgency=high
+
+ * Non-maintainer upload by the LTS Team.
+
+ -- Brian May Tue, 04 Feb 2020 17:25:44 +1100
+
ruby-rack-cors (0.2.9-1) unstable; urgency=low
* New upstream release
diff -Nru ruby-rack-cors-0.2.9/debian/patches/CVE-2019-18978.patch
ruby-rack-cors-0.2.9/debian/patches/CVE-2019-18978
Brian May writes:
> Here is a better stack trace (previous version was picking up system
> version of glib):
Here is an even better version of the even better version of the stack
trace that is actually useful (disabled compile time optimisation)
(gdb) bt
#0 0x772cbd08 in _g_log
n_suite_internal
(suite=suite@entry=0x610220, path=, path@entry=0x773b9fde
"") at gtestutils.c:2131
#15 0x7733bc6b in g_test_run_suite (suite=0x610220) at gtestutils.c:2184
#16 0x00007733bca1 in g_test_run () at gtestutils.c:1488
#17 0x00401361 in main (argc=1, argv=0x7fffeab8) at
network-monitor.c:536
(gdb)
--
Brian May
Brian May writes:
> commit 7cba800a84730c9c5843acdd775e42b8c1438edf (HEAD)
> Author: Alexander Larsson
> Date: Mon Jun 1 10:02:47 2015 +0200
This patch decreases the number of errors from 1 to 52.
(jessie-amd64-default)brian@silverfish:~/debian/lts/packages/glib2.0/glib$
gio/test
Brian May writes:
> With the 2nd patch, hangs, I pushed Ctrl-C to abort:
>
> (jessie-amd64-sbuild)brian@silverfish:/$
> /build/glib2.0-sBwZ3c/glib2.0-2.42.1/debian/build/deb/gio/tests/.libs/lt-network-monitor
> -k --tap
> # random seed: R02Sfd80eb1bd64b09d0b63ad8bc
2131
#13 0x7736b90b in g_test_run_suite (suite=0x611220) at
/build/glib2.0-sBwZ3c/glib2.0-2.42.1/./glib/gtestutils.c:2184
#14 0x7736b941 in g_test_run () at
/build/glib2.0-sBwZ3c/glib2.0-2.42.1/./glib/gtestutils.c:1488
#15 0x00401461 in main (argc=1, argv=0x7fffeb68) at
#/build/glib2.0-sBwZ3c/glib2.0-2.42.1/./gio/tests/network-monitor.c:536
--
Brian May
e glib2.0 breakage.
--
Brian May
1 - 100 of 515 matches
Mail list logo
