Re: qemu: CVE-2016-7116
> Yes, qemu is supported (and there has was lots of file renaming after > the Wheezy version). If you handle qemu please look at qemu-kvm as well > (they're the same version). Thanks for the hint. By the way, could you explain me why this CVE is still labeled RESERVED, although a public fix explaining the security issue has been released ? -- Hugo Lefeuvre (hle)|www.owl.eu.com 4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E signature.asc Description: PGP signature
Re: qemu: CVE-2016-7116
Hi Hugo, are you aware that this CVE is marked as in Jessie and soon will be in Wheezy as well. So unless you disagree with this , it would be better to avoid any potential regression and not upload qemu or qemu-kvm. Thorsten
Re: qemu: CVE-2016-7116
Hi Hugo, On Sun, Sep 04, 2016 at 01:25:56PM +0200, Hugo Lefeuvre wrote: > > Yes, qemu is supported (and there has was lots of file renaming after > > the Wheezy version). If you handle qemu please look at qemu-kvm as well > > (they're the same version). > > Thanks for the hint. > > By the way, could you explain me why this CVE is still labeled RESERVED, > although a public fix explaining the security issue has been released ? MITRE has assigned the CVE here: https://marc.info/?l=oss-security&m=147259351226835&w=2 . Basically that it is still RESERVED mean, that MITRE has not yet updated the corresponding description entry in their database, at some point then https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7116 will contain the MITRE provided description. Regards, Salvatore
Wheezy update of jsch?
Hello dear maintainer(s), the Debian LTS team would like to fix the security issues which are currently open in the Wheezy version of jsch: https://security-tracker.debian.org/tracker/source-package/jsch Would you like to take care of this yourself? If yes, please follow the workflow we have defined here: https://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-lts@lists.debian.org (via a debdiff, or with an URL pointing to the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. Indicate clearly whether you have tested the updated package or not. If you don't want to take care of this update, it's not a problem, we will do our best with your package. Just let us know whether you would like to review and/or test the updated package before it gets released. Thank you very much. Thorsten Alteholz, on behalf of the Debian LTS team. PS: A member of the LTS team might start working on this update at any point in time. You can verify whether someone is registered on this update in this file: https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
Wheezy update of libtomcrypt?
Hello Michael, the Debian LTS team would like to fix the security issues which are currently open in the Wheezy version of libtomcrypt: https://security-tracker.debian.org/tracker/CVE-2016-6129 Would you like to take care of this yourself? If yes, please follow the workflow we have defined here: https://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-lts@lists.debian.org (via a debdiff, or with an URL pointing to the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. Indicate clearly whether you have tested the updated package or not. If you don't want to take care of this update, it's not a problem, we will do our best with your package. Just let us know whether you would like to review and/or test the updated package before it gets released. Thank you very much. Thorsten Alteholz, on behalf of the Debian LTS team. PS: A member of the LTS team might start working on this update at any point in time. You can verify whether someone is registered on this update in this file: https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
Re: Wheezy update of libtomcrypt?
Thanks for your work on LTS. Time does not permit me to do any of this work myself. Please go ahead and make any changes as you see fit, there’s no need for my review. On Sun, Sep 4, 2016 at 5:38 PM, Thorsten Alteholz wrote: > Hello Michael, > > the Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of libtomcrypt: > https://security-tracker.debian.org/tracker/CVE-2016-6129 > > Would you like to take care of this yourself? > > If yes, please follow the workflow we have defined here: > https://wiki.debian.org/LTS/Development > > If that workflow is a burden to you, feel free to just prepare an > updated source package and send it to debian-lts@lists.debian.org > (via a debdiff, or with an URL pointing to the source package, > or even with a pointer to your packaging repository), and the members > of the LTS team will take care of the rest. Indicate clearly whether you > have tested the updated package or not. > > If you don't want to take care of this update, it's not a problem, we > will do our best with your package. Just let us know whether you would > like to review and/or test the updated package before it gets released. > > Thank you very much. > > Thorsten Alteholz, > on behalf of the Debian LTS team. > > PS: A member of the LTS team might start working on this update at > any point in time. You can verify whether someone is registered > on this update in this file: > https://anonscm.debian.org/viewvc/secure-testing/data/dla- > needed.txt?view=markup > > > -- Best regards, Michael
LTS report for August 2016
Hi, This month I was allocated 14.75 hours to work on Debian-LTS. I spent 13.5 hours doing the following: - openjdk-7: after some back and forth, finally pushed the update for openjdk-7 - icedtea-web: pushed the update to make icedtea-plugin default to openjdk-7 - fontconfig: prepared, tested and uploaded security update - tiff: prepared, tested and uploaded an update fixing several vulnerabilities. there still are some unfixed vulnerabilities which I'll look at soon - cacti: prepared and tested and pushed package to fix regression - gcc-4.8 & firefox: looked at building gcc-4.8 (gcc-mozilla) for wheezy. built and tested firefox_49.0~b1-1 against it Thanks, Emilio
Re: qemu: CVE-2016-7116
Hi Thorsten, On Sun, Sep 04, 2016 at 05:23:40PM +0200, Thorsten Alteholz wrote: > Hi Hugo, > > are you aware that this CVE is marked as in Jessie and soon will be > in Wheezy as well. > > So unless you disagree with this , it would be better to avoid any > potential regression and not upload qemu or qemu-kvm. no-dsa should be used very scarcely in LTS since we don't have a s-p-u to fix minor issues and reading the RedHat entry[1]: "A privileged user inside guest could use this flaw to access undue files on the host." I think we should well fix this vulnerability. Cheers, -- Guido [1]: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-7116
Re: qemu: CVE-2016-7116
Hi Guido, On Sun, 4 Sep 2016, Guido Günther wrote: no-dsa should be used very scarcely in LTS since we don't have a s-p-u to fix minor issues and reading the RedHat entry[1]: yes, but ... "A privileged user inside guest could use this flaw to access undue files on the host." ... you should also cite: "... host directory sharing via Plan 9 File System(9pfs) support ..." The latest news on [1] is from 2008. I am not sure whether there are really that much installations in the wild that really use it. I think we should well fix this vulnerability. I still think it is not needed. So qemu and qemu-kvm users: Do you use 9pfs on a Wheezy system? (me does not) Thorsten [1] http://9p.cat-v.org/News
Re: matrixssl
On 02/09/16 18:42, Brian May wrote: > sslio[8259]: fatal: unable to read cert or key file: no error I found that error reported in an unrelated bug report, the solution seems to be: https://bugs.contribs.org/show_bug.cgi?id=7664#c4 > I have been hit by the problem lamented by Jean Franco whiel deploying Netsol > released certificates. > > After much puzzling over the probLEM (I had done similar activities in the > past w/no problems whatsoever) I found out that converting the key with: > > openssl rsa -in a.key -out b.key > > and the cert with: > > openssl x509 -in a.key -out b.key > > (this last step i snot really necessary > > and then using the - functionially equivalent - b.crt, b.key in place of > a.crt, a.key makes the issue go away. > > The problem appears to lie with sslio being unable to interpret the key file > - the ones that failed begin with > -BEGIN PRIVATE KEY- > > while the onoe that succed begin with: > > -BEGIN RSA PRIVATE KEY- cheers, Chris -- Christopher SamuelSenior Systems Administrator VLSCI - Victorian Life Sciences Computation Initiative Email: sam...@unimelb.edu.au Phone: +61 (0)3 903 55545 http://www.vlsci.org.au/ http://twitter.com/vlsci
Re: qemu: CVE-2016-7116
On Sun, Sep 04, 2016 at 08:06:11PM +0200, Thorsten Alteholz wrote: > Hi Guido, > > On Sun, 4 Sep 2016, Guido Günther wrote: > > no-dsa should be used very scarcely in LTS since we don't have a s-p-u > > to fix minor issues and reading the RedHat entry[1]: > > yes, but ... > > > "A privileged user inside guest could use this flaw to access undue > > files on the host." > > ... you should also cite: > "... host directory sharing via Plan 9 File System(9pfs) support ..." Sorry for the omission, I thought that was clear from the context already. I know quiet some installations that share files via 9pfs between host and guest since this is the simplest way if you don't want to fiddle with network filesystems and it's easy to setup with common tools like libvirt/virt-manager. Cheers, -- Guido
