Accepted libssh2 1.4.3-4.1+deb8u6 (source amd64) into oldoldstable

2019-11-12 Thread Abhijith PA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 07 Nov 2019 11:54:30 +0530
Source: libssh2
Binary: libssh2-1 libssh2-1-dev libssh2-1-dbg
Architecture: source amd64
Version: 1.4.3-4.1+deb8u6
Distribution: jessie-security
Urgency: medium
Maintainer: Mikhail Gusarov 
Changed-By: Abhijith PA 
Description:
 libssh2-1  - SSH2 client-side library
 libssh2-1-dbg - SSH2 client-side library (debug package)
 libssh2-1-dev - SSH2 client-side library (development headers)
Closes: 943562
Changes:
 libssh2 (1.4.3-4.1+deb8u6) jessie-security; urgency=medium
 .
   * Non-maintainer upload by the Debian LTS Team.
   * Fix CVE-2019-17498: SSH_MSG_DISCONNECT logic in packet.c has an
 integer overflow in a bounds check (Closes: #943562)
Checksums-Sha1:
 9a8548e6afec27e522d0f922cec4b0603c7628ab 1928 libssh2_1.4.3-4.1+deb8u6.dsc
 c27ca83e1ffeeac03be98b6eef54448701e044b0 685712 libssh2_1.4.3.orig.tar.gz
 c8c8127cec1334a6c0e6874f015eeecdf6eea87a 22832 
libssh2_1.4.3-4.1+deb8u6.debian.tar.xz
 89862bf8b7b5e4afa25375315a0fb85f01c5d294 128440 
libssh2-1_1.4.3-4.1+deb8u6_amd64.deb
 e7d93310c4fe866bd1e8e1da2db2eb1ede48b5ed 293654 
libssh2-1-dev_1.4.3-4.1+deb8u6_amd64.deb
 5b731b3904553597947555f2e90376b7eb8cee7c 235072 
libssh2-1-dbg_1.4.3-4.1+deb8u6_amd64.deb
Checksums-Sha256:
 472132e47027254028064c6e7ff9e08f3788bdf3a7d9126a31a60fc4d4318601 1928 
libssh2_1.4.3-4.1+deb8u6.dsc
 eac6f85f9df9db2e6386906a6227eb2cd7b3245739561cad7d6dc1d5d021b96d 685712 
libssh2_1.4.3.orig.tar.gz
 a4784e7a346017251f032e67efc8b5a293189e2a2e25f7c2c0df87f1539d7d99 22832 
libssh2_1.4.3-4.1+deb8u6.debian.tar.xz
 1f0a01c4ba1434ec2e9c41fc0dc2d79685d8cdce0105be59a3f0aec96e48c333 128440 
libssh2-1_1.4.3-4.1+deb8u6_amd64.deb
 7e1421e616246574517ff20615dbf1df7d0e19a21fab44e12b3c7c46481c05d4 293654 
libssh2-1-dev_1.4.3-4.1+deb8u6_amd64.deb
 20e8ec190bc2acbc7d1d1b2c4ec503bf4a85b255db147c2af370516ae8947dbe 235072 
libssh2-1-dbg_1.4.3-4.1+deb8u6_amd64.deb
Files:
 2c3896a575ce8f98542b58d7192e99f8 1928 libs optional 
libssh2_1.4.3-4.1+deb8u6.dsc
 071004c60c5d6f90354ad1b701013a0b 685712 libs optional libssh2_1.4.3.orig.tar.gz
 d4153d47639d1c375c1cc106fd8bd508 22832 libs optional 
libssh2_1.4.3-4.1+deb8u6.debian.tar.xz
 f5bfcf019e9e112f6c3a9365de0579cd 128440 libs optional 
libssh2-1_1.4.3-4.1+deb8u6_amd64.deb
 c37dd51cc41f60aaf2e5c692531d1daf 293654 libdevel optional 
libssh2-1-dev_1.4.3-4.1+deb8u6_amd64.deb
 686a096d20ccf41327f6012a0920c3f1 235072 debug extra 
libssh2-1-dbg_1.4.3-4.1+deb8u6_amd64.deb

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEE7xPqJqaY/zX9fJAuhj1N8u2cKO8FAl3IFk8UHGFiaGlqaXRo
QGRlYmlhbi5vcmcACgkQhj1N8u2cKO9xVQ/+Mmc2eIJy1doNbgw7iF6qZ/8kmNL6
ktEUnagXojT9S1jw874bQVZSi2FnTMiJn7al1Wd2kKDAf5J+CvxBX4HzptrkBQBR
LWZe3jwjLS2hMj/iUd07cQmvpVPrrrqANrPLWfcwyPqg/up+o16HCa6lyALVcDmz
QNLusOHvcZcV42b/GXcgbmtVt1fBuaYfKNn3O96rzBeeGF3pCrR47zLrpLQj2+D0
VXf3BACrQJhbwkiTxYfZuBW3Lrdgj4I2m8Bu3REuRKZl7dyv3q2nMBSXHyIFwuKR
7fomggKI7eip5w9Ksmr3AD4XQ/nHcJF9a1o1bE8opTTyaY49Xfw/y3+51n17qZk9
fJ7XSHOo8FNmrSbUXetxjhLT0kmFejFfCtsDcKOonVLBG+x7ZVg1LondFPrtAwAz
iGObCr6/QG3W1m2WagEZQ0/AFHnmmyvFfSzu2iCGLPUpX3L3yQ55G4F8QmLHURUa
1EXrD6O9JusDdbEouhgMZ36dKmrIS5x2UMWSgUCUH+Gr1oFO29Y4kLlCWOeFGzeN
Qy96ht6dlVgeF0E8YNNIQGfqbxtSAj0cuCCEoH2SN+yIjOzyX0iTy88hCB3nn7Lc
rUtiS6UlPjKwEx+B0CHej71RRodsmGK+Dgky+QFBf5SZimyl1kGcWQbtnFRNYj9I
5/H6DDTLH8W/Y70=
=r6Ny
-END PGP SIGNATURE-



Re: Drop support for libqb?

2019-11-12 Thread Roberto C . Sánchez
On Tue, Nov 12, 2019 at 06:53:19PM +0100, Markus Koschany wrote:
> Hi,
> 
> Am 12.11.19 um 18:11 schrieb Roberto C. Sánchez:
> [...]
> > With that in mind, does this seem like a package for which we should
> > declare the end of support?
> 
> That sounds reasonable to me.
> 
Is it as simple as updating the debian-security-support package?  Do we
customarily send out a DLA when a package is dropped from support?

Regards,

-Roberto

-- 
Roberto C. Sánchez



[SECURITY] [DLA 1989-1] linux security update

2019-11-12 Thread Ben Hutchings
Package: linux
Version: 3.16.76-1
CVE ID : CVE-2019-0154 CVE-2019-11135

Several vulnerabilities have been discovered in the Linux kernel that
may lead to a privilege escalation, denial of service, or information
leak.

CVE-2019-0154

Intel discovered that on their 8th and 9th generation GPUs,
reading certain registers while the GPU is in a low-power state
can cause a system hang.  A local user permitted to use the GPU
can use this for denial of service.

This update mitigates the issue through changes to the i915
driver.

The affected chips (gen8) are listed at

;.

CVE-2019-11135

It was discovered that on Intel CPUs supporting transactional
memory (TSX), a transaction that is going to be aborted may
continue to execute speculatively, reading sensitive data from
internal buffers and leaking it through dependent operations.
Intel calls this "TSX Asynchronous Abort" (TAA).

For CPUs affected by the previously published Microarchitectural
Data Sampling (MDS) issues (CVE-2018-12126, CVE-2018-12127,
CVE-2018-12130, CVE-2019-11091), the existing mitigation also
mitigates this issue.

For processors that are vulnerable to TAA but not MDS, this update
disables TSX by default.  This mitigation requires updated CPU
microcode.  An updated intel-microcode package (only available in
Debian non-free) will be provided via a future DLA.  The updated
CPU microcode may also be available as part of a system firmware
("BIOS") update.

Further information on the mitigation can be found at


or in the linux-doc-3.16 package.

Intel's explanation of the issue can be found at

;.

For Debian 8 "Jessie", these problems have been fixed in version
3.16.76-1.  This update also includes other fixes from upstream stable
updates.

We recommend that you upgrade your linux packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS teams


signature.asc
Description: This is a digitally signed message part


Accepted linux 3.16.76-1 (all source) into oldoldstable

2019-11-12 Thread Ben Hutchings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 12 Nov 2019 15:56:11 +
Binary: linux-doc-3.16 linux-manual-3.16 linux-source-3.16 
linux-support-3.16.0-10
Source: linux
Architecture: all source
Version: 3.16.76-1
Distribution: jessie-security
Urgency: high
Maintainer: Debian Kernel Team 
Changed-By: Ben Hutchings 
Description: 
 linux-doc-3.16 - Linux kernel specific documentation for version 3.16
 linux-manual-3.16 - Linux kernel API manual pages for version 3.16
 linux-source-3.16 - Linux kernel source for version 3.16 with Debian patches
 linux-support-3.16.0-10 - Support files for Linux 3.16
Changes:
 linux (3.16.76-1) jessie-security; urgency=high
 .
   * New upstream stable update:
 https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.16.75
 - net/mlx4_core: Change the error print to info print
 - spi: bitbang: Fix NULL pointer dereference in spi_unregister_master
 - Btrfs: fix race between ranged fsync and writeback of adjacent ranges
 - scsi: bnx2fc: fix incorrect cast to u64 on shift operation
 - USB: Fix slab-out-of-bounds write in usb_get_bos_descriptor
 - USB: Add LPM quirk for Surface Dock GigE adapter
 - usbip: usbip_host: fix BUG: sleeping function called from invalid context
 - USB: rio500: fix memory leak in close after disconnect
 - [x86] drm/gma500/cdv: Check vbt config bits when detecting lvds panels
 - USB: serial: pl2303: add Allied Telesis VT-Kit3
 - usb: xhci: avoid null pointer deref when bos field is NULL
 - [armhf] net: stmmac: fix reset gpio free missing
 - igmp: acquire pmc lock for ip_mc_clear_src()
 - igmp: add a missing spin_lock_init()
 - ipv4/igmp: fix another memory leak in igmpv3_del_delrec()
 - sbitmap: fix improper use of smp_mb__before_atomic()
 - Input: uinput - add compat ioctl number translation for UI_*_FF_UPLOAD
 - perf/ring_buffer: Fix exposing a temporarily decreased data_head
 - perf/ring_buffer: Add ordering to rb->nest increment
 - i2c: dev: fix potential memory leak in i2cdev_ioctl_rdwr
 - configfs: Fix use-after-free when accessing sd->s_dentry
 - llc: fix skb leak in llc_build_and_send_ui_pkt()
 - CIFS: cifs_read_allocate_pages: don't iterate through whole page array on
   ENOMEM
 - usbip: usbip_host: fix stub_dev lock context imbalance regression
 - signal/ptrace: Don't leak unitialized kernel memory with
   PTRACE_PEEK_SIGINFO
 - net-gro: fix use-after-free read in napi_gro_frags()
 - kernel/signal.c: trace_signal_deliver when signal_group_exit
 - USB: usb-storage: Add new ID to ums-realtek
 - USB: Fix chipmunk-like voice when using Logitech C270 for recording
   audio.
 - hwmon: (pmbus/core) Treat parameters as paged if on multiple pages
 - net: rds: fix memory leak in rds_ib_flush_mr_pool
 - pktgen: do not sleep with the thread lock held.
 - can: af_can: Fix error path of can_init()
 - can: purge socket error queue on sock destruct
 - ipv6: flowlabel: fl6_sock_lookup() must use atomic_inc_not_zero
 - ptrace: restore smp_rmb() in __ptrace_may_access()
 - bcache: fix stack corruption by PRECEDING_KEY()
 - libata: Extend quirks for the ST1000LM024 drives with NOLPM quirk
 - cifs: add spinlock for the openFileList to cifsInodeInfo
 - fs/ocfs2: fix race in ocfs2_dentry_attach_lock()
 - coredump: fix race condition between collapse_huge_page() and core
   dumping
 - cfg80211: fix memory leak of wiphy device name
 - Btrfs: fix race between readahead and device replace/removal
 - btrfs: start readahead also in seed devices
 - be2net: Fix number of Rx queues used for flow hashing
 - neigh: fix use-after-free read in pneigh_get_next
 - perf/core: Fix perf_sample_regs_user() mm check
 - SMB3: retry on STATUS_INSUFFICIENT_RESOURCES instead of failing write
 - apparmor: enforce nullbyte at end of tag string
 - net: netem: fix backlog accounting for corrupted GSO frames
 - scsi: ufs: Avoid runtime suspend possibly being blocked forever
 - [x86] scsi: vmw_pscsi: Fix use-after-free in pvscsi_queue_lck()
 - [x86] apic: Fix integer overflow on 10 bit left shift of cpu_khz
 - be2net: fix link failure after ethtool offline test
 - perf/ioctl: Add check for the sample_period value
 - [x86] speculation: Allow guests to use SSBD even if host does not
 - cpu/speculation: Warn on unsupported mitigations= parameter
 - bonding: Always enable vlan tx offload
 - bonding: Add vlan tx offload to hw_enc_features
 - sctp: change to hold sk after auth shkey is created successfully
 - ALSA: seq: fix incorrect order of dest_client/dest_ports arguments
 - tracing/snapshot: Resize spare buffer if size changed
 - scsi: target/iblock: Fix overrun in WRITE SAME emulation
 - lib/mpi: Fix karactx leak in mpi_powm
 - crypto: user - prevent operating on larval algorithms
 

Re: Drop support for libqb?

2019-11-12 Thread Markus Koschany
Hi,

Am 12.11.19 um 18:11 schrieb Roberto C. Sánchez:
[...]
> With that in mind, does this seem like a package for which we should
> declare the end of support?

That sounds reasonable to me.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature


Drop support for libqb?

2019-11-12 Thread Roberto C . Sánchez
Hello all,

In recent days I made an attempt at backporting fixes made upstream in
libqb to address CVE-2019-12779.  I requested a review from upstream in
the related GitHub issue [0].

The essence of the discussion is that some important parts of the
upstream changes do not apply to the libqb in Jessie, because libqb in
Jessie is considerably older than the releases for which upstream has
provided a fix.

Chris and Brian have both made assessments of the degree of
vulnerability in libqb [1].  The comments from upstream appear to be in
line with those observed by Chris and Brian.  That said, Ferenc Wágner,
who is the current maintainer of libqb in Debian and also has
contributed upstream joined the conversation.  He asked what packages
depend on libqb.  I must confess that it never even occurred to me to
look.  The answer is that no packages depend on libqb in Jessie, making
it a leaf package.

Based on that and the vast differences between libqb 0.11.1, in Jessie,
and 1.0.5, in which the fixes have been made available, Ferenc's
assessment, and mine, is that additional effort on this package would be
a waste.  From Ferenc's point of view, anybody on such an old release of
Debian would have used 0.17.2 or 1.0.1 from jessie-backports.  Neither
of those will be updated by the security team.  Updating to a current
upstream release would be low risk from the standpoint of it being a
leaf package, but that does not seem right either.

With that in mind, does this seem like a package for which we should
declare the end of support?

Regards,

-Roberto

[0] https://github.com/ClusterLabs/libqb/issues/338
[1] https://lists.debian.org/debian-lts/2019/06/msg00015.html

-- 
Roberto C. Sánchez



Re: Security issues in standards (ruby-openid / CVE-2019-11027)

2019-11-12 Thread Utkarsh Gupta
Hi Sylvain, hi all,

On Thu, 7 Nov, 2019, 3:19 PM Sylvain Beucler,  wrote:

> Hi,
>
> On 06/11/2019 21:14, Utkarsh Gupta wrote:
> > On 06/11/19 11:47 am, Brian May wrote:
> >> Utkarsh Gupta  writes:
> >>
> >>> I am not quite sure about what should we do here because the update
> (DLA
> >>> 1956-1) doesn't quite fix the CVE completely and also brings some login
> >>> problems as reported in #125.
> >>> Because for now, #121 + #126 = actual CVE fix. But the login problem
> >>> remains.
> >> I guess we have three options:
> >>
> >> 1. Do nothing.
> >> 2. Revert the #121 patch, because it could break. I haven't seen any
> >> complaints however...
> > Whilst that is true, I'd rather not want someone to face an "unexpected
> > response" error.
> > Though I hope no one is using that feature yet :)
> >
> >> 3. Apply the #126 patch too. Not 100% convinced this is a justified
> >> change for LTS, but it "looks right".
> >> 4. Wait longer for possible upstream solution to #125.
> >>
> >> Any opinions?
> > I'd be a +1 on the 2nd and/or the 4th option. And a +0.5 on the 3rd.
> Do the package maintainers have an opinion on this?
> This can help.
>

I recently fixed (by fixing, I mean importing the CVE fix, not the problem
it causes) this in unstable and I'm one of the package maintainers now :)

Raphael, given that this package is low popcon and the vulnerability is
> fuzzy, do you know if the sponsor for this package would be willing to
> test fixes?
>

Given Raphael's last mail, I'm not sure if it could *really* be tested.
What makes sense now is to wait for the upstream fix *until* someone who
uses this library grumbles :)


Best,
Utkarsh

>


Re: Security issues in standards (ruby-openid / CVE-2019-11027)

2019-11-12 Thread Raphael Hertzog
Hi,

(Sylvain, please cc me if you want me to read something in any timely fashion)

On Thu, 07 Nov 2019, Sylvain Beucler wrote:
> Raphael, given that this package is low popcon and the vulnerability is
> fuzzy, do you know if the sponsor for this package would be willing to
> test fixes?

The sponsor is a web hoster who is listing packages used by all their
customers. I doubt that they can easily test.

I'm bccing them in case they want to chip in and express their interest
in testing fixes.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/



Re: (E)LTS report for October

2019-11-12 Thread Sylvain Beucler
Hi,

On 10/11/2019 21:41, Brian May wrote:
> Holger Levsen  writes:
>
>> then, just for the record, this was discussed with Raphael and me. Please
>> don't do more hours than assigned without coordination. See "What should
>> I do if I work more than the hours allocated?" in debian-lts.git for
>> more info.
> Huh? I don't see anything about requiring coordination here. Just bill
> the hours for your next month. Did I miss something?

I believe it's a matter of magnitude: the doc's example is about a 10%
excess, while this was about a ~200% excess.

Coordination allows to average the workload and reactivity, for instance
by adding more people to a task, reassigning the task, reconsidering the
task's scope, etc.
In this particular case it seems they decided to move the hours, but
that's not something one can decide on their own, at this scale.
(There may also be legal issues with billing hours while no hours were
done that particular month, AINAL.)

Cheers!
Sylvain