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
these open security issues aren't necessarily
serious issues that warrant concern.
Any ideas, comments?
Regards
--
Brian May
https://linuxpenguins.xyz/brian/
d 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
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
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
cidentally
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+git2
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
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
plan 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
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
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
updates. :
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
lise another limitation 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
l which 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
pass, 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
--- go
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
g, bytes.NewBuffer(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
I think.
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
n include 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/d
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
r 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?
--
B
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 updat
x27;t 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/
h
+
+ * Non-maintainer upload by the LTS Team.
+ * Fix CVE-2019-14868: An attacker could use flaw 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-maintaine
3/sh/pmain.c:45
I am guessing 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
00055db50ad5000 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 0x7f2658ae42e1 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
7f2ccedbd000
mmap(0x7f2ccedc3000, 14688, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2ccedc3000
close(3)= 0
arch_prctl(ARCH_SET_FS, 0x7f2ccefe5480) = 0
mprotect(0x7f2ccedbd000, 16384, PROT_READ) = 0
mprotect(0x5633d68d1000, 4096, PROT_READ) = 0
mp
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
here that lists
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'])) {
+ $path = $destination['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 t
nk we 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
n is completely 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
in a different file.
https://github.com/jquery/jquery/blob/d0ce00cdfa680f1f0c38460bc51ea14079ae8b07/src/core/parseHTML.js
--
Brian May
ample,
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
on
> will always return early 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 w
tooth 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
this security 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/
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
ckage again...
Regards
--
Brian May
https://linuxpenguins.xyz/brian/
ey
responded with:
> 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
Brian May writes:
> Hugo Lefeuvre writes:
>
>> xcftools:
>>
>> + create a reproducer for CVE-2019-5086 and write a patch (still waiting
>>for some external review).
>> + start to investigate CVE-2019-5087.
>
> I am a bit puzzled, what is the diffe
I can tell they both a the same vulnerability. Did I miss
something?
--
Brian May
now intend 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
r site, then
the cookie won't be transmitted from the browser and the user will not
have any login session, so damaging stuff using the user's credentials
is not possible.
--
Brian May
ut this was only implemented in PHP >=
7.3
https://www.php.net/manual/en/session.configuration.php
--
Brian May
t; such 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
is function 32, we actually get 32 bytes (=256
bits), or 64 digits.
irb(main):007:0> p SecureRandom.hex(1)
"82"
=> "82"
irb(main):006:0> p SecureRandom.hex(2)
"5fad"
=> "5fad"
--
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
I am still 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
his is 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
e substantial time to pull off." - wonder if it even worth
trying to fix this for anything other then unstable+testing.
--
Brian May
; 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
2 in g_test_run_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 0x7733bca1 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: R02Sfd80eb1bd64b09d0b63ad8bcdfd
ls.c: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
ut
the glib2.0 breakage.
--
Brian May
Brian May writes:
> My build is still running the tests, but I don't expect any problems as
> the test was getting skipped anyway...
Tests seem to be hanging, on the next test after:
PASS: network-address 37 /gresolver/resolve-address/0
PASS: network-address 38 /gresolver/resolv
Brian May writes:
> Emilio Pozuelo Monfort writes:
>
>> I have been looking at this, but building glib with only the two fix commits
>> (not the tests one) makes the build hang on the network-monitor tests. I
>> haven't
>> investigated much yet, but I wonder
e warnings being treated as errors
Makefile:3465: recipe for target 'libgio_2_0_la-gdbusauth.lo' failed
The patch removes a function called "hexencode" and replaces it with
"_g_dbus_hexencode". I wonder if it would be sufficient just to reverse
this bit of the change?
--
Brian May
Brian May writes:
> Apparently the fix for ibus creates a regression in glibc that must get
> fixed also:
>
> https://gitlab.gnome.org/GNOME/glib/merge_requests/1176
>
> However this patch patches GIO in glibc, and it looks like glibc in
> Jessie (2.19-18+deb8u10) doesn'
il, will make sure I check the
correct package tonight.
--
Brian May
hat I can see.
Hence, I am inclined to think maybe glibc doesn't need to be fixed in
Jessie.
--
Brian May
https://linuxpenguins.xyz/brian/
Windows,
before 1. ...)
NOT-FOR-US: Skype
CVE-2005-3266
=== cut ===
--
Brian May
@@
+angular.js (1.2.26-1+deb8u1) jessie-security; urgency=high
+
+ * Non-maintainer upload by the LTS Team.
+ * Fix CVE-2019-14863: properly sanitize xlink:href attribute interoplation.
+
+ -- Brian May Mon, 11 Nov 2019 17:39:43 +1100
+
angular.js (1.2.26-1) unstable; urgency=low
* New
1 - 100 of 527 matches
Mail list logo
