Re: qemu - CVE-2018-19665: bt subsystem mishandles negative length variables
On 1/12/19 5:52 PM, Hugo Lefeuvre wrote: the subsystem doesn't seem to be very actively maintained and that the user base is quite small, it is maybe better to mark this no-dsa in stretch and Please don't forget thet Debian has derivates that do not get summed up in popcon.d.o. So the user base might be bigger than assumed. Regards, Adrian.
A huge thank you!
Dear LTS Team Your work is greatly appreciated! I would like to thank you all for your effort. Without the LTS of wheezy it would have been a big pain for me. Thanks a lot for helping that much. Best regards, Adrian.
"highly critical" DRUPAL-PSA-2018-001
Dear LTS Team The Drupal Security Team announced a patch for Drupal 7 and 8 for March, 28th. The security hole is classified as "highly critical" [1]. They state that "because exploits might be developed within hours or days" one should update on March 28th 2018 between 18:00 - 19:30 UTC. I haven't read something about this vulnerability on the LTS mailing list, so I wanted to bring up your attention to it. Thank you! Best regards, Adrian. [1] https://www.drupal.org/psa-2018-001 signature.asc Description: OpenPGP digital signature
[SOLVED] Re: exim4 & libgnutls26: "A TLS packet with unexpected length was received."
Hi Antoine After some investigation I found that the count for the mentioned error was not slowly evolving, it was appearing at beginning of March a lot more than before. So I checked for changes on my side and found I had prolonged delays for hosts that are dns blacklisted too much (I set a small penalty for hosts on DNSRBL and a larger delay for positive spamassassin results to waste spammers resources). Some providers have very short time-outs and it seems TLS connection cannot be left open too long without sending anything anyway, which both leads to the error in my logs. Especially sendgrid has short delays and their hosts are often on blacklists, so I saw the error coming up very often with sendgrid hosts. As soon as I reduced the delay for blacklisted hosts to 15 seconds again instead of 35, the error disappeared and things run normally again now. So the error is mine and I apologize for the noise on the list. Thank you all for your answers. Best regards, Adrian. PS: I know it is bad practice to slow down legitimate connections, but I see it a good practice to slow down spammers. Systems that appear on blacklists do have a reason being listed and so the small penalty is acceptable in my opinion even though the message being received is a legitimate one. On 30.03.17 14:20, Antoine Beaupré wrote: > > So your first task is to contact the maintainer of that backport to make > sure it's updated, with a CC on the backports list. :) >
Re: exim4 & libgnutls26: "A TLS packet with unexpected length was received."
Hi Antoine On 29.03.17 22:21, Antoine Beaupré wrote: > On 2017-03-29 19:32:33, Adrian Zaugg wrote: > Litterally, "backporting" would mean uploading to wheezy-backports, and > there is already a backport there: I saw that one, but I think it is missing some security fixes. > Now, maybe a backport if *exim4* could be done. There's already one for > jessie, done by Andreas Metzler, and maybe you could ask him to do > another for wheezy. Ok, I try this if I find out that the error is less or no more seen with this versions. Thank you for your answer and to the others having replied. Regards, Adrian.
Re: exim4 & libgnutls26: "A TLS packet with unexpected length was received."
On 29.03.17 16:36, Antoine Beaupré wrote:
> Is this a regression in GnuTLS? Or just an aggravating problem from the
> rising adoption of SHA-512?
I don't think the only problem with libgnutls26 is SHA-512. As it seems
the mentioned error can occur in many situations, some for example write
about "the random size padding of packets to prevent communications
compromise for stream ciphers" [1]. I personally believe it is not
related to the SHA-512 issue, since the error from Exim is slightly
different in that case:
"...(gnutls_handshake): A TLS packet with..." opposed to the one I see
mostly "...(recv): A TLS packet with...".
To conclude: I don't know why that error occurs nor whether it came from
a regression or if it always has been there.
> I would tend towards fixing this only if it's the former, not the
> latter. This is, after all, why we want people to upgrade...
It is wise to upgrade in many situations and I completely agree that the
newer versions solve many problems. There are situations though, where
upgrading is difficult, is not yet feasible and for those situations LTS
is great.
Is backporting a newer version an option?
Regards, Adrian.
[1] comment #3 under
https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/882
--
.~..
_ //__
\°___/~~~
Adrian Zaugg
Zweierstrasse 56
CH-8004 Zürich
044 291 02 38
_
(This eMail gets best displayed
using a monospace font.)
exim4 & libgnutls26: "A TLS packet with unexpected length was received."
Dear Longtermers Watching the exim logs of my wheezy server, I discover a lot of connection aborts of incoming TLS connections. The error is quite generic: "A TLS packet with unexpected length was received." This seems to be a often observed problem since long time. Unfortunately the error is increasingly more often observed today compared to earlier, e.g. today vs. October 2015: 41% vs. 3% (Counting the error over one month in relation to the number of received messages). It occurs with ebay, sendgrid and few others. There are many TLS connections that do work well without an error. There are some bugs reports related to it, with a long history: #740160 - gnutls unusable with cacert SHA2-512 sigs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740160 #737921 - [TLS1.2] gnutls only likes SHA1 and SHA256 certificates https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921 #482404 - A TLS packet with unexpected length was received when receiving mail from MS Exchange 2003 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482404 #348046 - multiple GnuTLS issues - please only add information to blocking bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348046 One reason is libgnutls26 fails with sha512 keys, this can be worked around by adding the corresponding domains to tls_try_verify_exceptions. Unfortunately this is not a remedy for all connecting hosts, it works with gmx but not others. With the increasing number of this error emails get delayed or do not get delivered at all. I know LTS is not about fixing bugs, this one is critical though and it affects probably many wheezy installations. As it gets worse with time, it might be that some one would like to care anyway or maybe there is a known solution to this problem I haven't found in the net. Any advice is highly appreciated - I want to keep encrypted connections as the first option for connecting hosts. Thank you for your help! Best regards, Adrian Zaugg.
Re: Security update of openssh for wheezy
Is the security breech also present in openssh of wheezy-backports (openssh-server 1:6.6p1-4~bpo70+1, I guess yes because 1.6.0 and 1.6.7 are affected)? Is wheezy-backports in generally supported or not by the LTS Team? Thank you for your quick answer! Regards, Adrian. On 26.07.16 23:24, Ola Lundqvist wrote: > Hi OpenSSH Maintainers and LTS team > > I have prepared a security update of openssh for wheezy. > > For more information about the issue solved see here: > https://security-tracker.debian.org/tracker/CVE-2016-6210 > I have applied the same patch as in sid and it applied fine, except that > I had to change a call to a clear memory function to a loop instead. ...or > This function is not available in wheezy. > > You can find the debdiff here: > http://apt.inguza.net/wheezy-security/openssh/CVE-2016-6210.debdiff > > You can also find the packages that I intend to upload here: > http://apt.inguza.net/wheezy-security/openssh/ > > I have regression tested and I could login still, and use the client too. > I could not reproduce the problem good enough to tell for sure that they > are solved. However they should be solved just as good as in sid and jessie. > > If no-one objects I will upload this package in four days, that is on > Saturday. > > Best regards > > // Ola
Re: Re: Wheezy update of roundcube?
> On Tue, 03 May 2016 at 10:47:31 -0400, Antoine Beaupré wrote: >> I agree, however I suspect most people using roundcube in production are >> probably using the backport... There's even a dangling backport in >> wheezy right now (0.9)... a little messy. > Am 03.05.2016 um 17:49 schrieb Guilhem Moulin: >> Agreed, I think 0.9 should be either removed from the archive or >> superseeded by 1.0.x. To keep Roundcube 0.7.x and remove 0.9.x is not a good option in my opinion, I agree with Antoine that probably a lot of people using the backported 0.9.x version, since 0.7 is by far not as usable as 0.9. I would vote for a backported 1.0.x version or rather remove 0.7 than 0.9. Regards, Adrian.
