Re: improving https://wiki.debian.org/LTS/Development
I think it would be an improvement, yes. // Ola On Wed, 15 May 2019 at 15:08, Holger Levsen wrote: > Hi Christoph, > > I'm taking this to the lts list, as I think this deserves more peoples > thoughts: > > On Tue, May 14, 2019 at 04:56:43PM +0200, Christoph Berg wrote: > > As said elsewhere [...] I think part of the problem is > > that https://wiki.debian.org/LTS/Development is way too long. It > > shouldn't try to tell newcomers how to test packages etc, but just > > list the necessary steps required to a DLA. At the moment the "please > > also update webml" is hidden in a wall of text. And because the text > > is meant for newcomers, I'm not going to read it again for each > > upload. > > I agree that page is too long, and that a shorter checklist would be > very nice to have. And then it just occurred to me that the table of > content > on that page *is* that: > > Contents: > 3. Prepare security updates for LTS > > 1. Claim the issue in the security tracker (in dla-needed.txt) > 2. Build the update > 3. Test the update > 4. Upload the update > 5. Claim an DLA ID in DLA/list > 6. Announce the update > 7. Prepare an update for the website > > > Should we maybe put just this on a page called > https://wiki.debian.org/LTS/Development/TLDR > which then people can look at when they occasionally do a DLA? > > (and link to that TLDR page promininently from our other pages?) > > do you think this would be an improvement? Do you have other ideas? > > > (At the very least it could have a visible note at the top > > that says there was a recent change.) > > I'm not sure this will help that much... a.) people miss these notes and > then b.) how long ago is 'recent'? > > > -- > tschau, > Holger > > > --- >holger@(debian|reproducible-builds|layer-acht).org >PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
[SECURITY] [DLA 1789-1] intel-microcode security update
Package: intel-microcode Version: 3.20190514.1~deb8u1 CVE ID : CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 CVE-2019-11091 Debian Bug : 929007 This update ships updated CPU microcode for most types of Intel CPUs. It provides microcode support to implement mitigations for the MSBDS, MFBDS, MLPDS and MDSUM hardware vulnerabilities. To fully resolve these vulnerabilities it is also necessary to update the Linux kernel packages. Please refer to DLA-1787-1 for the Linux kernel updates required to mitigate these hardware vulnerabilities on Intel processors. For Debian 8 "Jessie", these problems have been fixed in version 3.20190514.1~deb8u1 of the intel-microcode package, and also by the Linux kernel package updates described in DLA-1787-1. We recommend that you upgrade your intel-microcode packages, and Linux kernel 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 For the detailed security status of intel-microcode please refer to its security tracker page at: https://security-tracker.debian.org/tracker/intel-microcode -- Henrique Holschuh signature.asc Description: PGP signature
Accepted intel-microcode 3.20190514.1~deb8u1 (amd64 i386 source) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 14 May 2019 22:00:43 -0300 Source: intel-microcode Binary: intel-microcode Architecture: amd64 i386 source Version: 3.20190514.1~deb8u1 Distribution: jessie-security Urgency: high Maintainer: Henrique de Moraes Holschuh Changed-By: Henrique de Moraes Holschuh Closes: 907402 Description: intel-microcode - Processor microcode firmware for Intel CPUs Changes: intel-microcode (3.20190514.1~deb8u1) jessie-security; urgency=high . * Rebuild for jessie-lts (no changes) . intel-microcode (3.20190514.1) unstable; urgency=high . * New upstream microcode datafile 20190514 * SECURITY UPDATE Implements MDS mitigation (RIDL, Fallout, Zombieload), INTEL-SA-00223 CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091 * New Microcodes: sig 0x00030678, pf_mask 0x02, 2019-04-22, rev 0x0838, size 52224 sig 0x00030678, pf_mask 0x0c, 2019-04-22, rev 0x0838, size 52224 sig 0x00030679, pf_mask 0x0f, 2019-04-23, rev 0x090c, size 52224 sig 0x000406c3, pf_mask 0x01, 2019-04-23, rev 0x0368, size 69632 sig 0x000406c4, pf_mask 0x01, 2019-04-23, rev 0x0411, size 68608 sig 0x00050657, pf_mask 0xbf, 2019-02-27, rev 0x521, size 47104 * Updated Microcodes: sig 0x000206a7, pf_mask 0x12, 2019-02-17, rev 0x002f, size 12288 sig 0x000306a9, pf_mask 0x12, 2019-02-13, rev 0x0021, size 14336 sig 0x000306c3, pf_mask 0x32, 2019-02-26, rev 0x0027, size 23552 sig 0x000306d4, pf_mask 0xc0, 2019-03-07, rev 0x002d, size 19456 sig 0x000306e4, pf_mask 0xed, 2019-03-14, rev 0x042e, size 16384 sig 0x000306e7, pf_mask 0xed, 2019-03-14, rev 0x0715, size 17408 sig 0x000306f2, pf_mask 0x6f, 2019-03-01, rev 0x0043, size 34816 sig 0x000306f4, pf_mask 0x80, 2019-03-01, rev 0x0014, size 18432 sig 0x00040651, pf_mask 0x72, 2019-02-26, rev 0x0025, size 21504 sig 0x00040661, pf_mask 0x32, 2019-02-26, rev 0x001b, size 25600 sig 0x00040671, pf_mask 0x22, 2019-03-07, rev 0x0020, size 14336 sig 0x000406e3, pf_mask 0xc0, 2019-04-01, rev 0x00cc, size 100352 sig 0x000406f1, pf_mask 0xef, 2019-03-02, rev 0xb36, size 30720 sig 0x00050654, pf_mask 0xb7, 2019-04-02, rev 0x25e, size 32768 sig 0x00050662, pf_mask 0x10, 2019-03-23, rev 0x001a, size 32768 sig 0x00050663, pf_mask 0x10, 2019-03-23, rev 0x717, size 24576 sig 0x00050664, pf_mask 0x10, 2019-03-23, rev 0xf15, size 23552 sig 0x00050665, pf_mask 0x10, 2019-03-23, rev 0xe0d, size 19456 sig 0x000506c9, pf_mask 0x03, 2019-01-15, rev 0x0038, size 17408 sig 0x000506ca, pf_mask 0x03, 2019-03-01, rev 0x0016, size 15360 sig 0x000506e3, pf_mask 0x36, 2019-04-01, rev 0x00cc, size 100352 sig 0x000506f1, pf_mask 0x01, 2019-03-21, rev 0x002e, size 11264 sig 0x000706a1, pf_mask 0x01, 2019-01-02, rev 0x002e, size 73728 sig 0x000806e9, pf_mask 0x10, 2019-04-01, rev 0x00b4, size 98304 sig 0x000806e9, pf_mask 0xc0, 2019-04-01, rev 0x00b4, size 99328 sig 0x000806ea, pf_mask 0xc0, 2019-04-01, rev 0x00b4, size 99328 sig 0x000806eb, pf_mask 0xd0, 2019-03-30, rev 0x00b8, size 98304 sig 0x000806ec, pf_mask 0x94, 2019-03-30, rev 0x00b8, size 97280 sig 0x000906e9, pf_mask 0x2a, 2019-04-01, rev 0x00b4, size 99328 sig 0x000906ea, pf_mask 0x22, 2019-04-01, rev 0x00b4, size 98304 sig 0x000906eb, pf_mask 0x02, 2019-04-01, rev 0x00b4, size 99328 sig 0x000906ec, pf_mask 0x22, 2019-02-14, rev 0x00ae, size 98304 sig 0x000906ed, pf_mask 0x22, 2019-03-17, rev 0x00b8, size 97280 . intel-microcode (3.20190312.1) unstable; urgency=medium . * New upstream microcode datafile 20190312 + Removed Microcodes: sig 0x00050653, pf_mask 0x97, 2018-01-29, rev 0x1000140, size 30720 + New Microcodes: sig 0x000806e9, pf_mask 0x10, 2018-10-18, rev 0x009e, size 98304 sig 0x000806eb, pf_mask 0xd0, 2018-10-25, rev 0x00a4, size 99328 sig 0x000806ec, pf_mask 0x94, 2019-02-12, rev 0x00b2, size 98304 sig 0x000906ec, pf_mask 0x22, 2018-09-29, rev 0x00a2, size 98304 sig 0x000906ed, pf_mask 0x22, 2019-02-04, rev 0x00b0, size 97280 + Updated Microcodes: sig 0x000306f2, pf_mask 0x6f, 2018-11-20, rev 0x0041, size 34816 sig 0x000306f4, pf_mask 0x80, 2018-11-06, rev 0x0013, size 17408 sig 0x00050654, pf_mask 0xb7, 2019-01-28, rev 0x25a, size 33792 sig 0x00050662, pf_mask 0x10, 2018-12-06, rev 0x0019, size 32768 sig 0x00050663, pf_mask 0x10, 2018-12-06, rev 0x716, size 23552 sig 0x00050664, pf_mask 0x10, 2018-11-17, rev 0xf14, size 23552 sig 0x00050665, pf_mask 0x10, 2018-11-17, rev 0xe0c, size 19456 sig 0x000506c9, pf_mask 0x03, 2018-09-14, rev 0x0036, size 17408 sig 0x000506ca, pf_mask 0x03, 2018-09-20, rev 0x0010, size 15360 sig 0x000706a1, pf_mask 0x01, 2018-09-21, rev 0x002c, size 73728 sig 0x000806e9, pf_mask
[SECURITY] [DLA 1787-1] linux-4.9 security update
Package: linux-4.9
Version: 4.9.168-1+deb9u2~deb8u1
CVE ID : CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 CVE-2019-11091
Debian Bug : 928125
Multiple researchers have discovered vulnerabilities in the way the
Intel processor designs have implemented speculative forwarding of data
filled into temporary microarchitectural structures (buffers). This
flaw could allow an attacker controlling an unprivileged process to
read sensitive information, including from the kernel and all other
processes running on the system or cross guest/host boundaries to read
host memory.
See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html
for more details.
To fully resolve these vulnerabilities it is also necessary to install
updated CPU microcode. An updated intel-microcode package (only
available in Debian non-free) will be provided via a separate DLA. The
updated CPU microcode may also be available as part of a system firmware
("BIOS") update.
In addition, this update includes a fix for a regression causing
deadlocks inside the loopback driver, which was introduced by the update
to 4.9.168 in the last security update.
For Debian 8 "Jessie", these problems have been fixed in version
4.9.168-1+deb9u2~deb8u1.
We recommend that you upgrade your linux-4.9 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
[SECURITY] [DLA 1788-1] samba security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: samba Version: 2:4.2.14+dfsg-0+deb8u13 CVE ID : CVE-2018-16860 Isaac Boukris and Andrew Bartlett discovered that the S4U2Self Kerberos extension used in Samba's Active Directory support was susceptible to man-in-the-middle attacks caused by incomplete checksum validation. For Debian 8 "Jessie", this problem has been fixed in version 2:4.2.14+dfsg-0+deb8u13. We recommend that you upgrade your samba 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 -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEcJymx+vmJZxd92Q+nUbEiOQ2gwIFAlzcfEYACgkQnUbEiOQ2 gwISkA/5AVU9SPoBNLSkliomQy8G/Ts7iuNpuieyCtRQP2BqjeNAYvRXmKbcW6EZ IcpfA4GpJc2Iro6X5dQSyfu4pucPCt79LNkDSz6Mf/UZ4yppbFUXF+fLSBj6NiDM F6eejQzzlA78VQsgGMBaMc4znGMqjZBWXBuin2SFfJNy/BS14Fp48eVYh2hoiDk6 6s4VgmIBX69lGGAYMhAI3W4Tf9EDu6IeCHbJ428qim1RKTq4kRUI3moTvJBkO80C F2NPpmd8cliX6sk5HFKVCX8F6vgOmh0v6wT2cUmb/mHHcSy/gtP8qUsL+9pJ4Kl9 gTqJfkV+VDVYktJKH3w0ZQwEAG0C3zV4Sm8hOeU0o71mgD0EnfMhHc/Eme2bKzRC kHw/jcu443rpqkuK+IZiYrhobDJ5NaILBsV5c4GTVV7NxYCwgzINdIhM5TDDXJf8 R3b6lpWIHtKfJ71T3orui7sKLengrJv0Y9fONfGOkIoExynOR4g+lixGc2sy1cRN euBhFdP4lG0HUnvzg0gIEZeLIfSwsWbCem9iterVd+oBrdrzIBV2CwkI9JCZkERw rgdPPbtaR9vpbGTNmwPPngz59U/TcuqrOrpQ+P8Oe+QcA7bpeD2tGJZa19DiwLda iOxjTkmu3uSM33gCusUlZP8zDJqXfkE0DNkPoJwayOSTkr58xMk= =mYiM -END PGP SIGNATURE-
Re: Bug in new libjs-jquery package from last week
Hi, On 14/05/2019 17:03, Brian May wrote: > Emilio Pozuelo Monfort writes: > >> It looks like the recent jquery update introduced a regression on the >> minified >> file. I see that you change how the minified file is built, which is likely >> to >> be related. Can you take a look? Also see the recently filed bug #928827. > > Thanks for raising my attention to this. > > My question is how did this ever get built in the first place on Jessie? > > I did not make any changes to the post compiler step, which appears to > be where the breakage is. All I did was fix the compiler step so that it > doesn't hang waiting forever for STDIN. Perhaps a change in some rdep between the previous jquery upload and yours broke it. In any case, this would need to be addressed, either by finding a solution to get the minified file properly built, or by just using the non-minified one. Cheers, Emilio
Re: Security update in Jessie for intel-microcode and linux?
On 5/15/19 2:51 PM, Ben Hutchings wrote: > On Wed, 2019-05-15 at 13:59 +0200, Thomas Goirand wrote: >> Hi, >> >> Probably Ben will reply to this one... >> >> Is it planned to upgrade intel-microcode and the kernel in Jessie, >> regarding CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 CVE-2019-11091? > > I plan to update linux, and I have backported the mitigation to 3.16. > However I will need to do more testing of this before uploading, and > will probably wait until it has been through the stable review process. > > I have already uploaded linux-4.9 to match the stable security update. > > I expect that Henrique will handle the intel-microcode update as he has > done before. > > Note that stable branches older than 4.9 are not getting the > speculation mitigations for KVM, and should not be used with untrusted > guests (at least on Intel hardware). > > Ben. Hi Ben, Thanks for your detailed answer. Cheers, Thomas Goirand (zigo)
improving https://wiki.debian.org/LTS/Development
Hi Christoph, I'm taking this to the lts list, as I think this deserves more peoples thoughts: On Tue, May 14, 2019 at 04:56:43PM +0200, Christoph Berg wrote: > As said elsewhere [...] I think part of the problem is > that https://wiki.debian.org/LTS/Development is way too long. It > shouldn't try to tell newcomers how to test packages etc, but just > list the necessary steps required to a DLA. At the moment the "please > also update webml" is hidden in a wall of text. And because the text > is meant for newcomers, I'm not going to read it again for each > upload. I agree that page is too long, and that a shorter checklist would be very nice to have. And then it just occurred to me that the table of content on that page *is* that: Contents: 3. Prepare security updates for LTS 1. Claim the issue in the security tracker (in dla-needed.txt) 2. Build the update 3. Test the update 4. Upload the update 5. Claim an DLA ID in DLA/list 6. Announce the update 7. Prepare an update for the website Should we maybe put just this on a page called https://wiki.debian.org/LTS/Development/TLDR which then people can look at when they occasionally do a DLA? (and link to that TLDR page promininently from our other pages?) do you think this would be an improvement? Do you have other ideas? > (At the very least it could have a visible note at the top > that says there was a recent change.) I'm not sure this will help that much... a.) people miss these notes and then b.) how long ago is 'recent'? -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Security update in Jessie for intel-microcode and linux?
On Wed, 2019-05-15 at 13:59 +0200, Thomas Goirand wrote: > Hi, > > Probably Ben will reply to this one... > > Is it planned to upgrade intel-microcode and the kernel in Jessie, > regarding CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 CVE-2019-11091? I plan to update linux, and I have backported the mitigation to 3.16. However I will need to do more testing of this before uploading, and will probably wait until it has been through the stable review process. I have already uploaded linux-4.9 to match the stable security update. I expect that Henrique will handle the intel-microcode update as he has done before. Note that stable branches older than 4.9 are not getting the speculation mitigations for KVM, and should not be used with untrusted guests (at least on Intel hardware). Ben. -- Ben Hutchings To err is human; to really foul things up requires a computer. signature.asc Description: This is a digitally signed message part
Accepted linux-4.9 4.9.168-1+deb9u2~deb8u1 (all source) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 14 May 2019 23:21:33 +0100 Binary: linux-doc-4.9 linux-headers-4.9.0-0.bpo.9-common linux-headers-4.9.0-0.bpo.9-common-rt linux-manual-4.9 linux-source-4.9 linux-support-4.9.0-0.bpo.9 Source: linux-4.9 Architecture: all source Version: 4.9.168-1+deb9u2~deb8u1 Distribution: jessie-security Urgency: high Maintainer: Debian Kernel Team Changed-By: Ben Hutchings Closes: 928125 Description: linux-doc-4.9 - Linux kernel specific documentation for version 4.9 linux-headers-4.9.0-0.bpo.9-common - Common header files for Linux 4.9.0-0.bpo.9 linux-headers-4.9.0-0.bpo.9-common-rt - Common header files for Linux 4.9.0-0.bpo.9-rt linux-manual-4.9 - Linux kernel API manual pages for version 4.9 linux-source-4.9 - Linux kernel source for version 4.9 with Debian patches linux-support-4.9.0-0.bpo.9 - Support files for Linux 4.9 Changes: linux-4.9 (4.9.168-1+deb9u2~deb8u1) jessie-security; urgency=medium . * Backport to jessie; no further changes required . linux (4.9.168-1+deb9u2) stretch-security; urgency=high . [ Salvatore Bonaccorso ] * Revert "block/loop: Use global lock for ioctl() operation." (Closes: #928125) . linux (4.9.168-1+deb9u1) stretch-security; urgency=high . * [x86] Update speculation mitigations: - x86/MCE: Save microcode revision in machine check records - x86/cpufeatures: Hide AMD-specific speculation flags - x86/bugs: Add AMD's variant of SSB_NO - x86/bugs: Add AMD's SPEC_CTRL MSR usage - x86/bugs: Switch the selection of mitigation from CPU vendor to CPU features - x86/bugs: Fix the AMD SSBD usage of the SPEC_CTRL MSR - x86/microcode/intel: Add a helper which gives the microcode revision - x86/microcode/intel: Check microcode revision before updating sibling threads - x86/microcode: Make sure boot_cpu_data.microcode is up-to-date - x86/microcode: Update the new microcode revision unconditionally - x86/mm: Use WRITE_ONCE() when setting PTEs - bitops: avoid integer overflow in GENMASK(_ULL) - x86/speculation: Simplify the CPU bug detection logic - locking/atomics, asm-generic: Move some macros from to a new file - x86/speculation: Remove SPECTRE_V2_IBRS in enum spectre_v2_mitigation - x86/cpu: Sanitize FAM6_ATOM naming - Documentation/l1tf: Fix small spelling typo - x86/speculation: Apply IBPB more strictly to avoid cross-process data leak - x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation - x86/speculation: Propagate information about RSB filling mitigation to sysfs - x86/speculation/l1tf: Drop the swap storage limit restriction when l1tf=off - x86/speculation: Update the TIF_SSBD comment - x86/speculation: Clean up spectre_v2_parse_cmdline() - x86/speculation: Remove unnecessary ret variable in cpu_show_common() - x86/speculation: Move STIPB/IBPB string conditionals out of cpu_show_common() - x86/speculation: Disable STIBP when enhanced IBRS is in use - x86/speculation: Rename SSBD update functions - x86/speculation: Reorganize speculation control MSRs update - x86/Kconfig: Select SCHED_SMT if SMP enabled - sched: Add sched_smt_active() - x86/speculation: Rework SMT state change - x86/l1tf: Show actual SMT state - x86/speculation: Reorder the spec_v2 code - x86/speculation: Mark string arrays const correctly - x86/speculataion: Mark command line parser data __initdata - x86/speculation: Unify conditional spectre v2 print functions - x86/speculation: Add command line control for indirect branch speculation - x86/speculation: Prepare for per task indirect branch speculation control - x86/process: Consolidate and simplify switch_to_xtra() code - x86/speculation: Avoid __switch_to_xtra() calls - x86/speculation: Prepare for conditional IBPB in switch_mm() - x86/speculation: Split out TIF update - x86/speculation: Prepare arch_smt_update() for PRCTL mode - x86/speculation: Prevent stale SPEC_CTRL msr content - x86/speculation: Add prctl() control for indirect branch speculation - x86/speculation: Enable prctl mode for spectre_v2_user - x86/speculation: Add seccomp Spectre v2 user space protection mode - x86/speculation: Provide IBPB always command line options - kvm: x86: Report STIBP on GET_SUPPORTED_CPUID - x86/msr-index: Cleanup bit defines - x86/speculation: Consolidate CPU whitelists - Documentation: Move L1TF to separate directory - cpu/speculation: Add 'mitigations=' cmdline option - x86/speculation: Support 'mitigations=' cmdline option - x86/speculation/mds: Add 'mitigations=' support for MDS - x86/cpu/bugs: Use __initconst for 'const' init data * [x86] Mitigate Microarchitectural Data Sampling (MDS) vulnerabilities (CVE-2018-12126,
Security update in Jessie for intel-microcode and linux?
Hi, Probably Ben will reply to this one... Is it planned to upgrade intel-microcode and the kernel in Jessie, regarding CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 CVE-2019-11091? Cheers, Thomas Goirand (zigo)
Re: dns-root-data in Jessie LTS
Ping ? :) On 13/05/2019 21:14, Sylvain Beucler wrote: > Hi, > > AFAICS dns-root-data has no reverse-dependency in Jessie (I ran the > script in a more recent box and got confused). > Does it make sense to update it after all? > > bind9 ships 3 keys in /etc/bind/bind.keys with the comment "Servers > which were already using the old key (19036) should roll seamlessly to > this new one via RFC 5011 rollover" - hmm, so isn't this working as > intended? > > unbound doesn't seem to ship any key (I only see the old 19036 in > testdata/ in the source package). > However it populated /var/lib/unbound/root.key with 20326 on install. > > Cheers! > Sylvain > > On 13/05/2019 20:45, Ondřej Surý wrote: >> Hi Sylvain, >> >> I am actually not sure whether BIND 9 in Jessie already uses dns-root-data, >> so maybe same procedure will be needed for bind9 package. >> >> Could you perhaps also check unbound? >> >> This is the most probable cause of the weird traffic with old key that DNS >> Root Operators >> see at root servers. >> >> Just make sure it contains only the new DNSKEY (2017) and not both. >> >> Thanks, >> Ondrej >> -- >> Ondřej Surý >> ond...@isc.org >> >>> On 14 May 2019, at 01:38, Sylvain Beucler wrote: >>> >>> Hi, >>> >>> On 13/05/2019 05:43, Ondřej Surý wrote: could you please update dns-root-data package in Jessie LTS to latest version from Unstable/Stretch? >>> I'll backport it following dkg's stretch update. >>> >>> Besides setting up a bind9, anything we should test? >>> >>> Cheers! >>> Sylvain
