linux backport in jessie LTS
The backports team decided in 2016 that backports suites will no longer be updated once the corresponding stable suite enters LTS. This implies that jessie-backports will be closed at the end of May. It is clear that a fair number of wheezy LTS users relied on backported kernel versions and were caught out when this policy was applied to wheezy (and not announced as clearly as it could have been). I would not be surprised if this recurs with jessie. Therefore, would it make sense to add a Linux 4.9 backport to the regular jessie and jessie-security suites? Are there users currently running jessie with Linux 4.9 and expecting to continue doing so through the LTS period? (Maintaining kernel backports is generally quite easy once the suite they are backported from is stable.) Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Re: ruby1.9.1 test packages for wheezy
El 19/04/18 a las 18:07, Gabriel Filion escribió: > Hi there, > > I've run a test on our setup here after getting a poke from Antoine. > > I'm not sure that the test is actually conclusive of anything though.. > basically, it still works for us but that's probably because of how > things are setup. > > we run the puppet master with passenger > > plus we've had some weird issues with puppet master 2.7 + ruby 1.9.3 so > we're forcing the default ruby to be 1.8.7 on the master. > > after upgrade of ruby, clients were still able to run against the > puppetmaster. > Thanks for your feedback, Gabriel! I will finish the upload for 1.9.1, and include one for 1.8 along too. I am still working on jessie and stretch versions. Santiago signature.asc Description: PGP signature
Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat
It looks like this buffer overflow is the consequence of an earlier buffer
overflow in the GetNextCodeCompat macro:
> #define GetNextCodeCompat(sp, bp, code) { \
> nextdata |= (unsigned long) *(bp)++ << nextbits;\
> nextbits += 8; \
> if (nextbits < nbits) { \
> nextdata |= (unsigned long) *(bp)++ << nextbits;\
> nextbits += 8; \
> } \
> code = (hcode_t)(nextdata & nbitsmask); \
> nextdata >>= nbits; \
> nextbits -= nbits; \
> }
The raw data buffer is read using the bp pointer without proper bound checking.
At some point, we start to read garbage, store it into the code variable which
is later used to create the codep. This invalid codep later triggers the second
overflow.
So now the question is: Why is this first buffer overflow happening ?
My guess is that the sample is declaring more strips than actually available, or
declares strips with incorrect size. I still have to check that however.
Regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
signature.asc
Description: PGP signature
