Accepted libav 6:11.12-1~deb8u3 (source all amd64) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 20 Dec 2018 22:56:40 +0100 Source: libav Binary: libav-tools libav-dbg libav-doc libavutil54 libavcodec56 libavdevice55 libavformat56 libavfilter5 libswscale3 libavutil-dev libavcodec-dev libavdevice-dev libavformat-dev libavfilter-dev libswscale-dev libavresample-dev libavresample2 libavcodec-extra-56 libavcodec-extra Architecture: source all amd64 Version: 6:11.12-1~deb8u3 Distribution: jessie-security Urgency: medium Maintainer: Debian Multimedia Maintainers Changed-By: Mike Gabriel Description: libav-dbg - Debug symbols for Libav related packages libav-doc - Documentation of the Libav API libav-tools - Multimedia player, encoder and transcoder libavcodec-dev - Development files for libavcodec libavcodec-extra - Libav codec library (additional codecs meta-package) libavcodec-extra-56 - Libav codec library (additional codecs) libavcodec56 - Libav codec library libavdevice-dev - Development files for libavdevice libavdevice55 - Libav device handling library libavfilter-dev - Development files for libavfilter libavfilter5 - Libav video filtering library libavformat-dev - Development files for libavformat libavformat56 - Libav file format library libavresample-dev - Development files for libavresample libavresample2 - Libav audio resampling library libavutil-dev - Development files for libavutil libavutil54 - Libav utility library libswscale-dev - Development files for libswscale libswscale3 - Libav video scaling library Changes: libav (6:11.12-1~deb8u3) jessie-security; urgency=medium . * Non-maintainer upload by the Debian LTS Team. * debian/patches: + Rename CVE-2015-6822+6823+6824.patch to CVE-2015-6822.patch.. * CVE-2015-6823: avcodec/alac: Clear pointers in allocate_buffers(). * CVE-2015-6824: swscale/utils: Clear pix buffers. Fixes use of uninitialized memory. Checksums-Sha1: 29d44a844fa91d3e58b59c0fecffcad703f0694f 4023 libav_11.12-1~deb8u3.dsc c95dd3ebdfa67b08e322cefd4cd0bab675fb7a88 64084 libav_11.12-1~deb8u3.debian.tar.xz f45a1706ec161786d6cbf9ff441f0a3970d62700 18440680 libav-doc_11.12-1~deb8u3_all.deb 218d1e154982d2ed142400f878d8027db06f2f4e 65586 libavcodec-extra_11.12-1~deb8u3_all.deb ac38727c8a386c598e9844a0814f95db6694fba4 473170 libav-tools_11.12-1~deb8u3_amd64.deb b0165b5fd1569b0547902dec55ee53dde1dc3c57 21598842 libav-dbg_11.12-1~deb8u3_amd64.deb a80efde1fc4584fb8f912b49fee6bf7500c55aba 130554 libavutil54_11.12-1~deb8u3_amd64.deb 78e7dcb4d2356ef7b9da3693099a6ca31b5a0711 3109018 libavcodec56_11.12-1~deb8u3_amd64.deb 2e356abfc5ae6bc3a7ee3617133763e8e35aeef2 90472 libavdevice55_11.12-1~deb8u3_amd64.deb 495cde59d9d4253e24e717fefdc2c79a358ec250 584778 libavformat56_11.12-1~deb8u3_amd64.deb 6c758874e9c03d7727d69f2006a28aa31b809b21 171510 libavfilter5_11.12-1~deb8u3_amd64.deb c385a07fa663c68c6e4e0cdc6d55fd6cd8378c90 144048 libswscale3_11.12-1~deb8u3_amd64.deb d12dec592e3d4b7f1641dab81e96ae53ff0ef65d 192708 libavutil-dev_11.12-1~deb8u3_amd64.deb 91049d76fe517514e037f7be72eec4eccf79d973 3431348 libavcodec-dev_11.12-1~deb8u3_amd64.deb a97688201cace4e815cf0d9c2f1bb64dadd5b432 93520 libavdevice-dev_11.12-1~deb8u3_amd64.deb 7fe72d2f70943675ae6649af1112343300ff8917 690694 libavformat-dev_11.12-1~deb8u3_amd64.deb 288cf0e05e874a9af94f08dea0ac64abed20d83b 202772 libavfilter-dev_11.12-1~deb8u3_amd64.deb 79d3b5b016db6e6b59b2f208a22a701e513d5634 157042 libswscale-dev_11.12-1~deb8u3_amd64.deb 267a4a68a4ca3d788a95a9f6352aeb08f66c1377 111936 libavresample-dev_11.12-1~deb8u3_amd64.deb 18169fb3a773033045b6ee7451de8d64eff6ff56 102996 libavresample2_11.12-1~deb8u3_amd64.deb 1ab3995529e6c2dc4b13ac745f67fd7ae6a0667f 3112894 libavcodec-extra-56_11.12-1~deb8u3_amd64.deb Checksums-Sha256: 3122af21a12824407e6bf80979951a839168bc890a3cd73a45e4262565aa068f 4023 libav_11.12-1~deb8u3.dsc 1e13db8b055a502f05e49138fe9b6692a9ffb11305b39d7e8182a90fce4b39c9 64084 libav_11.12-1~deb8u3.debian.tar.xz 9cdcfaa805a4546065aed516404b581fd64604a33d3a5877323b522307305171 18440680 libav-doc_11.12-1~deb8u3_all.deb 49f13b0f5c57c59a31073a4ed5fb272b8ca9cac646c0c77eb818e52f907c8776 65586 libavcodec-extra_11.12-1~deb8u3_all.deb 83855e75e09a71ccc59f220e9c0e6fbe0567b1f87e841333728579c7e75def2f 473170 libav-tools_11.12-1~deb8u3_amd64.deb 2e4780be773991478890fe8e050678fd28d189f6f4c0957b4da9dccfbd06d2f6 21598842 libav-dbg_11.12-1~deb8u3_amd64.deb a3e364cbae86694c7fed85e95cf48cf8f260d5b94e6c1783ec0ec7ce57a95b3e 130554 libavutil54_11.12-1~deb8u3_amd64.deb cb17453126e3199c7992f083cf3abd16917630965c255c0db00cca68330e5f62 3109018 libavcodec56_11.12-1~deb8u3_amd64.deb ebc77cac26b8c78fba2dc298de503bc0960a202b380554f5b17bd7b1c4ad55de 90472 libavdevice55_11.12-1~deb8u3_amd64.deb bdc081cd347334caeffa1637c44a488370fcd87035078f39be41844e87e0d9de 584778 libavformat56_11.12-1~deb8u3_amd64.deb 515b034d2c8ba59c802d88bc3d8a7e12db9b55c5b4a02cbde4bb158b84098cf5 171510
[SECURITY] [DLA 1611-1] libav security update
Package: libav Version: 6:11.12-1~deb8u2 CVE ID : CVE-2014-9317 CVE-2015-6761 CVE-2015-6818 CVE-2015-6820 CVE-2015-6821 CVE-2015-6822 CVE-2015-6825 CVE-2015-6826 CVE-2015-8216 CVE-2015-8217 CVE-2015-8363 CVE-2015-8364 CVE-2015-8661 CVE-2015-8662 CVE-2015-8663 CVE-2016-10190 CVE-2016-10191 Several security issues have been corrected in multiple demuxers and decoders of the libav multimedia library. CVE-2014-9317 The decode_ihdr_chunk function in libavcodec/pngdec.c allowed remote attackers to cause a denial of service (out-of-bounds heap access) and possibly had other unspecified impact via an IDAT before an IHDR in a PNG file. The issue got addressed by checking IHDR/IDAT order. CVE-2015-6761 The update_dimensions function in libavcodec/vp8.c in libav relies on a coefficient-partition count during multi-threaded operation, which allowed remote attackers to cause a denial of service (race condition and memory corruption) or possibly have unspecified other impact via a crafted WebM file. This issue has been resolved by using num_coeff_partitions in thread/buffer setup. The variable is not a constant and can lead to race conditions. CVE-2015-6818 The decode_ihdr_chunk function in libavcodec/pngdec.c did not enforce uniqueness of the IHDR (aka image header) chunk in a PNG image, which allowed remote attackers to cause a denial of service (out-of-bounds array access) or possibly have unspecified other impact via a crafted image with two or more of these chunks. This has now been fixed by only allowing one IHDR chunk. Multiple IHDR chunks are forbidden in PNG. CVE-2015-6820 The ff_sbr_apply function in libavcodec/aacsbr.c did not check for a matching AAC frame syntax element before proceeding with Spectral Band Replication calculations, which allowed remote attackers to cause a denial of service (out-of-bounds array access) or possibly have unspecified other impact via crafted AAC data. This has now been fixed by checking that the element type matches before applying SBR. CVE-2015-6821 The ff_mpv_common_init function in libavcodec/mpegvideo.c did not properly maintain the encoding context, which allowed remote attackers to cause a denial of service (invalid pointer access) or possibly have unspecified other impact via crafted MPEG data. The issue has been resolved by clearing pointers in ff_mpv_common_init(). This ensures that no stale pointers leak through on any path. CVE-2015-6822 The destroy_buffers function in libavcodec/sanm.c did not properly maintain height and width values in the video context, which allowed remote attackers to cause a denial of service (segmentation violation and application crash) or possibly have unspecified other impact via crafted LucasArts Smush video data. The solution to this was to reset sizes in destroy_buffers() in avcodec/sanm.c. CVE-2015-6823 Other than stated in the debian/changelog file, this issue has not yet been fixed for libav in Debian jessie LTS. CVE-2015-6824 Other than stated in the debian/changelog file, this issue has not yet been fixed for libav in Debian jessie LTS. CVE-2015-6825 The ff_frame_thread_init function in libavcodec/pthread_frame.c mishandled certain memory-allocation failures, which allowed remote attackers to cause a denial of service (invalid pointer access) or possibly have unspecified other impact via a crafted file, as demonstrated by an AVI file. Clearing priv_data in avcodec/pthread_frame.c has resolved this and now avoids stale pointer in error case. CVE-2015-6826 The ff_rv34_decode_init_thread_copy function in libavcodec/rv34.c did not initialize certain structure members, which allowed remote attackers to cause a denial of service (invalid pointer access) or possibly have unspecified other impact via crafted (1) RV30 or (2) RV40 RealVideo data. This issue got addressed by clearing pointers in ff_rv34_decode_init_thread_copy() in avcodec/rv34.c, which avoids leaving stale pointers. CVE-2015-8216 The ljpeg_decode_yuv_scan function in libavcodec/mjpegdec.c in FFmpeg omitted certain width and height checks, which allowed remote attackers to cause a denial of service (out-of-bounds array access) or possibly have unspecified other impact via crafted MJPEG data. The issues have been fixed by adding a check for index to avcodec/mjpegdec.c in ljpeg_decode_yuv_scan() before using it, which fixes an out of array access. CVE-2015-8217 The ff_hevc_parse_sps function in libavcodec/hevc_ps.c did not validate the Chroma Format Indicator, which allowed remote attackers to cause a denial of service (out-of-bounds array access) or possibly have unspecified other impact via crafted
Re: proposed removal of Enigmail from jessie/LTS
fwiw, i agree with jmm that encouraging users to upgrade to stable is the best outcome here. The question is, what are we doing to the folks who (for whatever reason) can't make that switch. On Thu 2018-12-20 17:01:30 +0100, Moritz Mühlenhoff wrote: > If suddenly all kinds of core libraries are getting updated in jessie > (with minimal testing) we're not talking about "all kinds of core libraries" -- we're talking about a very selected subset. And i don't think we're talking about "minimal testing", there has been a reasonable amount of testing. I think we ought to consider this specific case, rather than trying to make a systematized rule. > EOLing enigmail seems the only sensible option by far. the main issue with EOLing enigmail is that users will (instead of upgrading to stable) typically just use the version from addons.mozilla.org, which has both non-DFSG-free issues and significantly scary behavior (downloading and silently executing binaries from the web on the user's behalf). If we're EOLing thunderbird on jessie entirely, that'd be one thing (and i'd be ok with it). But EOLing enigmail on its own sounds like a route to trouble for enigmail users on jessie. --dkg signature.asc Description: PGP signature
Re: Xen 4.4 updates vs. Xen Stretch backport
Hi, Holger, > Holger Levsen hat am 19. Dezember 2018 um 16:33 > geschrieben: > On Fri, Dec 07, 2018 at 01:32:49PM +0100, Peter Dreuw wrote: > > go to https://salsa.debian.org/security-tracker-team as a logged in user > and you will see a button "request access" (unless you are already a > member.) Thank you. I already got accepted for https://salsa.debian.org/security-tracker-team/security-tracker/project_members > > and the documentation at > > https://wiki.debian.org/LTS/Development#Prepare_security_updates_for_Jessie_LTS > > says, this list here is one of the three options to request this access. > > right. and it works :) Even more seriously, I just fixed the URL for the > first option on that page. > > How are the Xen 4.4 fixes coming along? I'm afraid, I have not make any advance yet. I was so busy getting every thing done in front of the coming holidays that I didn't find time to sit down and concentrate on this. I am really sorry for this. I'll be on vacation until 6th of January, 2019. I assume, will have a chance to start working focused on this when I'm back from vacation. All the best for Christmas and a happy new year to all of you out there! cheers, Peter -- Peter Dreuw Teamleiter Tel.: +49 2166 9901-155 Fax: +49 2166 9901-100 E-Mail: peter.dr...@credativ.de gpg fingerprint: 33B0 82D3 D103 B594 E7D3 53C7 FBB6 3BD0 DB32 ED41 https://www.credativ.de/ credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Re: openssl 1.0 support on stretch LTS
On 2018/12/13 20:59, Emilio Pozuelo Monfort wrote: > On 06/12/2018 05:11, Haruki TSURUMOTO wrote: >> Hi, >> my questions intents >> Will get openssl1.0 package security-update by LTS team from 2020 to >> 2022-mid? >> (Only selected packages are supported in LTS surely) >> Debian stretch has two openssl pakcages. >> >> https://packages.debian.org/ja/source/stretch/openssl >> https://packages.debian.org/ja/source/stretch/openssl1.0 >> >> I think old one(openssl1.0) is difficult to maintenance after upstream >> support end.(31st December 2019) > > I believe we will have to support 1.0.2 as some important software (e.g. > openssh) use 1.0 in stretch. We will be backporting fixes, and other > distributors (Ubuntu LTS, RedHat) will probably have to support 1.0.x so we > can > share and reuse patches with them. I understood. Thank you! -- Haruki TSURUMOTO PGP Fingerprint:3718 C84E 4EDA 1B5C 4F26 8639 9D3D EE3F 63A6 000E signature.asc Description: OpenPGP digital signature
Re: proposed removal of Enigmail from jessie/LTS
On Wed, Dec 19, 2018 at 05:03:26PM +, Holger Levsen wrote: > I mostly worried that you didnt test all dependent packages and that we > essentially might break those when trying to support a package no > customer has expressed need for. But then I also suppose such breakage > could be fixed... But the very basic idea of a LTS release is to avoid the risk of breakage. If suddenly all kinds of core libraries are getting updated in jessie (with minimal testing) I'd need to run extensive tests when deploying this change sensibly and if such extensive tests are needed, I could just as well upgrade to stable. We'd never do such a change in a regular oldstable/stable either. EOLing enigmail seems the only sensible option by far. After all, there's a solid alternative if there's actually remaining Enigmail users on jessie; upgrading to Stretch. Cheers, Moritz
Accepted libav 6:11.12-1~deb8u2 (source all amd64) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 19 Dec 2018 14:31:49 +0100 Source: libav Binary: libav-tools libav-dbg libav-doc libavutil54 libavcodec56 libavdevice55 libavformat56 libavfilter5 libswscale3 libavutil-dev libavcodec-dev libavdevice-dev libavformat-dev libavfilter-dev libswscale-dev libavresample-dev libavresample2 libavcodec-extra-56 libavcodec-extra Architecture: source all amd64 Version: 6:11.12-1~deb8u2 Distribution: jessie-security Urgency: medium Maintainer: Debian Multimedia Maintainers Changed-By: Mike Gabriel Description: libav-dbg - Debug symbols for Libav related packages libav-doc - Documentation of the Libav API libav-tools - Multimedia player, encoder and transcoder libavcodec-dev - Development files for libavcodec libavcodec-extra - Libav codec library (additional codecs meta-package) libavcodec-extra-56 - Libav codec library (additional codecs) libavcodec56 - Libav codec library libavdevice-dev - Development files for libavdevice libavdevice55 - Libav device handling library libavfilter-dev - Development files for libavfilter libavfilter5 - Libav video filtering library libavformat-dev - Development files for libavformat libavformat56 - Libav file format library libavresample-dev - Development files for libavresample libavresample2 - Libav audio resampling library libavutil-dev - Development files for libavutil libavutil54 - Libav utility library libswscale-dev - Development files for libswscale libswscale3 - Libav video scaling library Changes: libav (6:11.12-1~deb8u2) jessie-security; urgency=medium . * Non-maintainer upload by the Debian LTS Team. * CVE-2014-9317: avcodec/pngdec: Check IHDR/IDAT order. Prevent remote attackers from causing a denial of service (out-of-bounds heap access) and possibly have other unspecified impact via an IDAT before an IHDR in a PNG file. * CVE-2015-6761: avcodec/vp8: Do not use num_coeff_partitions in thread/buffer setup. The variable is not a constant and can lead to race conditions. * CVE-2015-6818: avcodec/pngdec: Only allow one IHDR chunk. Multiple IHDR chunks are forbidden in PNG. Fixes inconsistency and out of array accesses. * CVE-2015-6820: avcodec/aacsbr: check that the element type matches before applying SBR. Fixes out of array access. * CVE-2015-6821: avcodec/mpegvideo: Clear pointers in ff_mpv_common_init(). This ensures that no stale pointers leak through on any path. * CVE-2015-6822, CVE-2015-6823, CVE-2015-6824: avcodec/sanm: Reset sizes in destroy_buffers(). * CVE-2015-6825: avcodec/pthread_frame: clear priv_data, avoid stale pointer in error case. * CVE-2015-6826: avcodec/rv34: Clear pointers in ff_rv34_decode_init_thread_copy(). Avoids leaving stale pointers. * CVE-2015-8216: avcodec/mjpegdec: Check index in ljpeg_decode_yuv_scan() before using it. Fixes out of array access. * CVE-2015-8217: avcodec/hevc_ps: Check chroma_format_idc. Fixes out of array access. * CVE-2015-8363: avcodec/jpeg2000dec: Check for duplicate SIZ marker. * CVE-2015-8364: avcodec/ivi: Check image dimensions. Fixes integer overflow. * CVE-2015-8661: avcodec/h264_slice: Limit max_contexts when slice_context_count is initialized. Fixes out of array access. * CVE-2015-8662: avcodec/jpeg2000dwt: Check ndeclevels before calling dwt_decode*(). Fixes out of array access. * CVE-2015-8663: avcodec/utils: Clear dimensions in ff_get_buffer() on failure. Fixes out of array access. * CVE-2016-10190: http: make length/offset-related variables unsigned. Required cherry-picking 3668701f and 362c17e6 from ffmpeg.git. * CVE-2016-10191: avformat/rtmppkt: Check for packet size mismatches. Fixes out of array access. Checksums-Sha1: dddc80889e64e8e01cee06d145d7913befbf32fb 4023 libav_11.12-1~deb8u2.dsc 61d5dcab5fde349834af193a572b12a5fd6a4d42 4865624 libav_11.12.orig.tar.xz a46c5abf3539d805b46c577fbdcd9c1bc81e70eb 63348 libav_11.12-1~deb8u2.debian.tar.xz c68b8cb7a40af736d4fac5f2df14f833d66e7ba8 18439966 libav-doc_11.12-1~deb8u2_all.deb e66e60e2e3cf007a1187c3fc294d0d838bc274c3 65506 libavcodec-extra_11.12-1~deb8u2_all.deb d00bcba1eaae7f6243a487f4503bfc0520606359 472802 libav-tools_11.12-1~deb8u2_amd64.deb 8216ee04b089f67ebac48bf6ef57e42a8b76bb49 21598990 libav-dbg_11.12-1~deb8u2_amd64.deb 766a029a861ccf4d517d2309f9f2416039a958b2 130458 libavutil54_11.12-1~deb8u2_amd64.deb eeec171f3f8a13030d7792711ba32d601b71bce4 3108822 libavcodec56_11.12-1~deb8u2_amd64.deb 97eb8a3c424cbb77664240ff4231f687bc7eac78 90414 libavdevice55_11.12-1~deb8u2_amd64.deb 700dcdbfec70e85ab4857d640b2e60655b427bf1 584780 libavformat56_11.12-1~deb8u2_amd64.deb e5cb11481c516110116900e5c9e70a630c5d6282 171674 libavfilter5_11.12-1~deb8u2_amd64.deb aa28082b695da7ab9c63cea1ce94755ba0c8bc02 143968 libswscale3_11.12-1~deb8u2_amd64.deb 7e001b1d5ccd14037cc51b46de1da49a4002d6ff 192632
Re: HEADS UP: upcoming change to libgcrypt and other gnupg libraries for Enigmail backport
On 2018-12-20 Daniel Kahn Gillmor wrote: [...] > On Wed 2018-12-19 11:59:46 -0500, Antoine Beaupré wrote: >> On 2018-12-18 14:34:06, Emilio Pozuelo Monfort wrote: >>> libgcrypt is a bit more worrying, even after dropping most of the noise: >>> $ diff libgcrypt20-1.*/ | filterdiff -x '*.pc/*' -x '*/debian/*' -x >>> '*/tests/*' >>> | diffstat | tail -1 >>> 263 files changed, 51927 insertions(+), 14888 deletions(-) >> Yeah, that's my concern as well. >> Daniel, what do you think of that diff? Is that something we can >> reasonably review? How much can we expect stability in that upgrade? >> I know you stated before general principles of gpg vs lib / API >> stability, but I'd be curious to hear your thoughts on gcrypt, in this >> specific case. > I agree that an upgrade to gcrypt is the biggest risk here, and i'm not > sure how to evaluate it other than running what meager rdep test suites > we have in jessie. I don't know whether anyone who has been working on > ci.debian.net is following this discussion, but i think it points to > some really salient use cases for test infrastructure. How nice it > would be if a DD could upload a prospective package and say "please run > all test suites for reverse dependencies!" > Andreas Metzler (cc'ed here) has been a stalwart steward of gcrypt in > debian for many years, even after GnuTLS switched to nettle, and > probably has the best sense of what kind of system integration dangers > might lurk in the proposed upgrade for jessie. Perhaps he can comment > on it? [...] Hello, looking at my mail archive gcrypt updates since 1.6 (i.e. since the last soname bump) have been very painless. The only breakage in rdeps I found was #816104, going from 1.6 to 1.7. http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/4487 cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#916912: [pre-approval] stretch-pu: package freerdp/1.1.0~git20140921.1.440916e+dfsg1-13+deb9u3
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Dear Debian stretch Release Team, in Debian LTS, we are currently discussing a complex update of the freerdp (v1.1) package. The current status is this: * since March 2018 freerdp in stretch (and jessie) (Git snapshot of never released v1.1) is unusable against latest Windows servers. All Windows OS versions switched to RDP proto version 6 plus CredSSP version 3) and the freerdp versions in Debian jessie/stretch do not support that. * for people using Debian stretch, the only viable work-around is using freerdp2 from stretch-backports. * people using Debian jessie LTS don't have any options (except from upgrading to stretch and using freerdp2 from stretch-bpo). * currently, we know of four unfixed CVE issues in freerdp (v1.1) (that are fixed in buster's freerdp2. With my Debian LTS contributor hat on, I have started working on the open freerdp CVE issues (which luckily appeared in a Ubuntu security update, so not much work on this side) _and_ ... ... I have started backporting the required patches (at least these: [1,2,3]) to get RDP proto version 6 working in Debian jessie's freerdp v1.1 version. This complete endeavour for LTS only makes sense if the stable release team is open to accepting such a complex change to Debian stretch, too. While working on these patches, I regularly get feedback from FreeRDP upstream developer Bernhard Miklautz. The Git version [4] of the proposed upload is not yet ready. After feedback from Bernhard, I will have to backport various WinPR API calls that are used around the RDP proto v6 implementation. So this whole thing is still work in progress. The reason for this mail is: if the stable release team declines this update, then we neither will bring it to Debian jessie LTS. Please give me a beacon single (mainly a "yes, go ahead", or a "no, no way!"). Please let me know, if you need more info to consider. Cheers, Mike [1] https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/blob/debian/stretch/updates/debian/patches/0010_add-support-for-credssp-version-3.patch [2] https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/blob/debian/stretch/updates/debian/patches/0011_add-support-for-proto-version-6.patch [3] https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/blob/debian/stretch/updates/debian/patches/0012-fix-nla-don-t-use-server-version.patch [4] https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/tree/debian/stretch/updates -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: policykit-1 CVE-2018-19788 in jessie
On Thu, Dec 20, 2018 at 03:11:49PM +0530, Abhijith PA wrote: > Hi Santiago, > > On Thursday 20 December 2018 01:00 AM, Santiago Ruano Rincón wrote: > > Dear Maintainers, > > > > (It seems my first attempt to send this mail failed. Sorry if you > > received it twice) > > > > As opposed to stretch, I have been unable to reproduce CVE-2018-19788 in > > jessie. i.e. systemctl correctly doesn't allow me to stop services, and > > pkexec blocks me from executing applications that need privileges. > > I couldn't reproduce in my jessie machine either. > > > Do you think is it safe to consider jessie as not-affected? Or is it > > still worth to apply the patch? > > I think its okay to mark as not-affected. Don't mark issues as not-affected just because some specific reproducer doesn't trigger. This should only be done if source code analysis has shown it to be not affected. Cheers, MOritz
Re: policykit-1 CVE-2018-19788 in jessie
Hi Santiago, On Thursday 20 December 2018 01:00 AM, Santiago Ruano Rincón wrote: > Dear Maintainers, > > (It seems my first attempt to send this mail failed. Sorry if you > received it twice) > > As opposed to stretch, I have been unable to reproduce CVE-2018-19788 in > jessie. i.e. systemctl correctly doesn't allow me to stop services, and > pkexec blocks me from executing applications that need privileges. I couldn't reproduce in my jessie machine either. > Do you think is it safe to consider jessie as not-affected? Or is it > still worth to apply the patch? I think its okay to mark as not-affected. --abhijith
