Re: Intended MBF: maintainer scripts not using strict mode
On Mon, Jun 26, 2017 at 11:09:26PM +0200, Mattia Rizzolo wrote: > On Mon, Jun 26, 2017 at 10:23:56PM +0200, Ralf Treinen wrote: > > we currently have in sid 84 maintainer scripts not using strict mode. > > That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e". > > The list is attached. This list includes the 12 remaining scripts not > > starting on #! (bugs are already filed for these). > > sigh. > And using `#!/bin(ba)?sh -e` is not good either (there is a lintian tag > about it, iirc). what is the rationale for this? Is anyone calling maintainer scripts like "sh
Re: Intended MBF: maintainer scripts not using strict mode
On Tue, Jun 27, 2017 at 07:01:56AM +0200, Johannes Schauer wrote: > Hi, > > Quoting Christoph Biedl (2017-06-27 00:37:33) > > Let's be honest: Shell scripts, while easy to write, carry too many risks of > > unsafe programming. So while your proposed fixing is a step in the right > > direction, this is all just band-aid. We (as in Debian) should look forward > > and try to replace these maintainer scripts with something more error-prone. > > Niels has mentioned declarative approaches which seem like a good idea. No > > idea about the status, though, and I'm interested in details if there > > already > > are some. > > this might've exactly been the angle that made Ralf find these issues with > maintainer scripts in the first place: > > https://debconf16.debconf.org/talks/63/ > > https://www.irif.fr/~treinen/colis/ yes, indeed, this is a first step of our project. -Ralf.
Re: Intended MBF: maintainer scripts not using strict mode
On Tue, Jun 27, 2017 at 01:21:01PM +0800, Paul Wise wrote: > On Tue, Jun 27, 2017 at 4:23 AM, Ralf Treinen wrote: > > > we currently have in sid 84 maintainer scripts not using strict mode. > > That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e". > > The list is attached. This list includes the 12 remaining scripts not > > starting on #! (bugs are already filed for these). > > Looks like you were talking about these bugs: > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=colis-shparser;users=trei...@debian.org Until now we have been putting our bugs under a generic colis-shparser usertag. Maybe we should start using more specific usertags in addition. > > What is your opinion? Policy says "should", not "must". If you agree > > with the MBF, what do you think would be the appropriate severity? > > I note that naively adding "set -e" can make shell scripts more > brittle, especially when using diff or other commands that can return > failure in unforeseen circumstances. When doing the MBF, please remind > people to read their scripts, note the range of exit codes for each > command and add "|| true" for commands that return failure exit codes > that do not indicate failures or indicate conditions that should not > terminate the maintainer script. Yes, that is a good idea. I have seen indeed quite some scripts in the corpus (not the ones against which I intend to file bugs) which do a selective "set +e"/"set -e" around commands that require careful error handling. > PS: will you be packaging the software produced by the CoLiS project? yes, of course :-) > PPS: the lintshell link on the CoLiS website requires a login. lintshell isn't ready for publication yet (the link on our project website was premature). -Ralf.
Declarative packaging (Was: Re: Intended MBF: maintainer scripts not using strict mode)
Christoph Biedl: > [...] Niels has mentioned declarative approaches which seem > like a good idea. No idea about the status, though, and I'm interested > in details if there already are some. > > Christoph > Hi, Up till now, we deal with some easy wins by converting debhelper maintscripts to triggers. I plan to phase out the maintscripts from one more helper in buster (if everything turns out nicely). * But then we are out of easy wins. * Plus none of this would rid us of manually written scripts (like the ones Ralf brought up) After this, we need something other than triggers. Triggers are great for regenerating global caches but they are not good at delegating targeted functionality out like: * This package needs user X to be created dynamically with home set to H with login shell S. * This package wants to enable and start service Y, but obviously first after creating user X (which the service runs as) * The user X also needs to own a few files or directories at location Z (possibly including the home directory H). Ideally, this should be done before starting the service Y. Furthermore, we also need to fix some paper-cuts such as #822462, so we do not regress every time a conffile is removed or changes it name. The next items in this topic basically all requires changes to dpkg, which I have not done at this scale yet. I will probably spend most of buster on other items (like a few release team processes). Thanks, ~Niels
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
* Ben Hutchings: > On Mon, 2017-06-26 at 08:34 +, Holger Levsen wrote: >> On Sun, Jun 25, 2017 at 09:19:36AM -0300, Henrique de Moraes Holschuh wrote: >> [...] >> > Apparently, Intel had indeed found the issue, *documented it* (see >> > below) and *fixed it*. There was no direct feedback to the OCaml >> > people, so they only found about it later. > [...] >> so in conclusion: don't buy intel. At least in future. > [...] > > Other procesors aren't bug-free, they just don't get as many bug fixes. And the fixes aren't documented publicly at all.
Re: IMPORTANT: Do live Debian images have a future?
at bottom :- On 26/06/2017, Steve McIntyre wrote: > [ Note the cross-posting... ] > > Hey folks, > > Background: we released live images for Stretch using new tooling, > namely live-wrapper. It is better than what we had before (live-build) > in a number of ways, particularly in terms of build reliability and > some important new features (e.g. UEFI support). But it's also less > mature and has seen less testing. There have been bugs because of > that. I have fixes for most of the ones I know about [1], and I'm > still working on more bugfixes yet. > > While the bugs are annoying, what worries me more is that they were > only spotted in release builds. There had been testing versions of > live images available for multiple weeks beforehand, presumably with > the same bugs included. (Almost) none of them reported. This shows > that we don't have enough people using these live images and/or caring > about filing bugs. > > We have a similar lack of involvement in terms of the content of the > live images. As I said above, I'm happy that we now have a reliable > tool for building our live images - that makes my life much > easier. But I honestly have no idea if the multiple desktop-specific > live images are actually reasonable representations of each of the > desktops. For example, I *seriously* hope that normal KDE > installations are not effected by #865382 like our live KDE > images. Validation by the various desktop teams would be useful here. > > The current situation is *not* good enough. I ended up getting > involved in live image production because the images needed making, > and I was already the main person organising production of Debian's > official images. To be frank, I had (and still have) no direct use for > the live images myself and I don't *particularly* care about them all > that much. Despite that, I've ended up spending a lot of time working > on them. A few other people have also spent a lot of time working in > this area - thanks are due to those people too. But it's still not > enough. > > If our live images are going to be good enough to meet the standards > that Debian users deserve and expect, we need *consistent*, > *sustained* involvement from a lot more people. Please tell me if > you're going to help. If we don't see a radical improvement soon, I'll > simply disable building live images altogether to remove the false > promises they're making. > > [1] > https://get.debian.org/images/release/current-live/amd64/iso-hybrid/#issues > > -- > Steve McIntyre, Cambridge, UK. > st...@einval.com > "...In the UNIX world, people tend to interpret `non-technical user' > as meaning someone who's only ever written one device driver." -- Daniel > Pead > One of the things at least to my mind is we (the users) do not know which is most closest testing release near to the final release. For e.g. take the last/latest announcement done by Cyril Brulebois on 13th June talking about the Stretch RC5 release. In the whole announcement, there is not even a hint to potential testers that this might be the closest to the final released (gold) image. I am presuming/assuming that Cyril was also talking about the live image and not the just the installer improvements. What would be nicer/better perhaps if debian-live does announcements on d-d-a and more importantly hint as when it's going to be nearer to release (final image). We are going to have a release party this week-end in Pune (haven't posted the details yet at https://wiki.debian.org/ReleasePartyStretch , hoping the organizers will do the needful otherwise will do it in a day or two. I/we could also have testing parties before the release as well with a two-week window to the final image . This also gives times to students to see how things work in the real world as well. I can't volunteer for any activities atm (due to health issues) except for taking part in organising testing party in Pune before release and getting more people to file bugs in case they hit problems. I am hopeful we can find a better way/solution to the above. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Corruption in CPU
Hello, I saw your article on corrupted data and I have reason to believe that the bad code goes as far back to Intel Pentium D processors, in my investigation I have seen that when hyperthreading is disabled the cpu acts ok no corrupted data or corrupted downloads however when enabled the corrupted data starts showing up and changing md5 completely.
Bug#866099: ITP: libtwelvemonkeys-java -- collection of plugins and extensions for Java's ImageIO
Package: wnpp Severity: wishlist Owner: Markus Koschany * Package name: libtwelvemonkeys-java Version : 3.3.2 Upstream Author : Harald Kuhr * URL : https://github.com/haraldk/TwelveMonkeys * License : BSD-3-clause, ASL Programming Lang: Java Description : collection of plugins and extensions for Java's ImageIO These plugins extend the number of image file formats supported in Java, using the javax.imageio.* package. The main purpose of this project is to provide support for formats not covered by the JRE itself. Supported image formats (read and write support may vary): BMP, JPEG, JPEG-2000, PNM, PSD, TIFF, HDR, IFF, PCX, PICT, SGI, TGA, ICNS, ICO & CUR, Thumbs.db, SVG and WMF. This package is a new dependency to package the latest version of pdfsam. It will be maintained within the Debian Java team.
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
(updated perl script, it now needs the "liblist-moreutils-perl" package)
On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote:
> On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote:
> > This warning advisory is relevant for users of systems with the Intel
> > processors code-named "Skylake" and "Kaby Lake". These are: the 6th and
> > 7th generation Intel Core processors (desktop, embedded, mobile and
> > HEDT), their related server processors (such as Xeon v5 and Xeon v6), as
> > well as select Intel Pentium processor models.
>
> Attached, you will find a perl script that can help detect if your
> system is affected or not. Many thanks to Uwe Kleine-König for
> suggesting, and writing this script.
Uwe Kleine-König was kind enough to update the perl script to fix the
broken hyper-threading detection. The new version is attached.
NOTE: You may need to install the liblist-moreutils-perl package for the
script to work.
--
Henrique Holschuh
#!/usr/bin/perl
# Copyright 2017 Uwe Kleine-König
#
# This program is free software; you can redistribute it and/or modify it under
# the terms of the GNU General Public License version 2 as published by the
# Free Software Foundation.
use List::MoreUtils 'uniq';
open(my $cpuinfo, ") {
if (/^$/) {
push @cpus, { %cpu };
undef %cpu;
}
$cpu{'cpunum'} = $1 if /^processor\s*:\s(.*)/;
$cpu{'vendor'} = $1 if /^vendor_id\s*:\s(.*)/;
$cpu{'family'} = $1 if /^cpu family\s*:\s(.*)/;
$cpu{'model'} = $1 if /^model\s*:\s(.*)/;
$cpu{'stepping'} = $1 if /^stepping\s*:\s(.*)/;
$cpu{'microcode'} = $1 if /^microcode\s*:\s(.*)/;
$cpu{'core id'} = $1 if /^core id\s*:\s(.*)/;
}
my $num_cpus = @cpus;
my $num_cores = uniq map { $_->{'core id'} } @cpus;
foreach (@cpus) {
print "cpu " . $_->{cpunum} . ": ";
if ($_->{'vendor'} eq "GenuineIntel" and $_->{'family'} == 6) {
my $model = $_->{'model'};
if ($model == 78 or $model == 94) {
if ($_->{'stepping'} eq "3") {
my $microcoderev = $_->{'microcode'};
print "Your CPU is affected, ";
if (hex($microcoderev) >= 0xb9) {
print "but your microcode is new enough\n";
} elsif ($num_cpus == $num_cores) {
print "but hyper threading is off, which works around the problem\n";
} else {
print "you should install the latest intel-microcode\n";
}
} else {
print "You may need a BIOS/UEFI update (unknown Skylake-Y/H/U/S stepping)\n";
}
} elsif ($model == 85 or $model == 142 or $model == 158) {
print "You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)\n";
print "Note: Kaby Lake X-series processors (i7-7740X, etc) are not affected\n";
} else {
print "You're likely not affected\n";
}
} else {
print "You're not affected\n";
}
}
Re: IMPORTANT: Do live Debian images have a future?
And I'll add my 2¢ as an end user. The live images exist IMHO to test compatibility before committing to installation, and to install what was just tested and demonstrated, regardless of environment. It's a nice feature (arguably an essential feature) that the actual install mirror *exactly* the tested compatibility and appearance. To go with this, it *was* nice to be able to install in the absence of a network connection or Internet service. The Live environment still works fine for testing for compatibility, especially when the Nonfree repository is included. Installation, no longer. My 2¢ is that installation suffers from a lack of testing, probably because Debian Live is a "unofficial" branch off the development tree. It's made worse because bugs for Live have no clear reporting process. Where DOES one report a problem - to this mailing list, or the mailing list more obviously suited (think a bug found while installing...report here, or report to debian-install, or to debian-boot)? Inquiring minds want to know! Charlie On Jun 26, 2017 12:55 PM, "Michael ." wrote: > I'm not a dev but I am a user and I do test so I'll add my bit here. > > Let's be frank Live Wrapper only exists because of animosity within Debian > towards the originator of Live Build (and to be honest his own lack of > concern for what Debian required of Live Build). Live Wrapper was rushed > and was never going to be ready for Stretch and in hindsight it was a > little foolish to think it would be ready to build the types of images > Debian required. Live Build wasn't up to scratch but the UEFI support issue > has been fixed so what other issues are there with Live Build that makes it > unreasonable to use? > > On 27 June 2017 at 00:08, Steve McIntyre wrote: > >> [ Note the cross-posting... ] >> >> Hey folks, >> >> Background: we released live images for Stretch using new tooling, >> namely live-wrapper. It is better than what we had before (live-build) >> in a number of ways, particularly in terms of build reliability and >> some important new features (e.g. UEFI support). But it's also less >> mature and has seen less testing. There have been bugs because of >> that. I have fixes for most of the ones I know about [1], and I'm >> still working on more bugfixes yet. >> >> While the bugs are annoying, what worries me more is that they were >> only spotted in release builds. There had been testing versions of >> live images available for multiple weeks beforehand, presumably with >> the same bugs included. (Almost) none of them reported. This shows >> that we don't have enough people using these live images and/or caring >> about filing bugs. >> >> We have a similar lack of involvement in terms of the content of the >> live images. As I said above, I'm happy that we now have a reliable >> tool for building our live images - that makes my life much >> easier. But I honestly have no idea if the multiple desktop-specific >> live images are actually reasonable representations of each of the >> desktops. For example, I *seriously* hope that normal KDE >> installations are not effected by #865382 like our live KDE >> images. Validation by the various desktop teams would be useful here. >> >> The current situation is *not* good enough. I ended up getting >> involved in live image production because the images needed making, >> and I was already the main person organising production of Debian's >> official images. To be frank, I had (and still have) no direct use for >> the live images myself and I don't *particularly* care about them all >> that much. Despite that, I've ended up spending a lot of time working >> on them. A few other people have also spent a lot of time working in >> this area - thanks are due to those people too. But it's still not >> enough. >> >> If our live images are going to be good enough to meet the standards >> that Debian users deserve and expect, we need *consistent*, >> *sustained* involvement from a lot more people. Please tell me if >> you're going to help. If we don't see a radical improvement soon, I'll >> simply disable building live images altogether to remove the false >> promises they're making. >> >> [1] https://get.debian.org/images/release/current-live/amd64/iso >> -hybrid/#issues >> >> -- >> Steve McIntyre, Cambridge, UK. >> st...@einval.com >> "...In the UNIX world, people tend to interpret `non-technical user' >> as meaning someone who's only ever written one device driver." -- Daniel >> Pead >> > >
Bug#866111: ITP: standardskriver -- Tool for dynamically setting a user's default printer at desktop session logon
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel
* Package name: standardskriver
Version : 0.0.2
Upstream Author : Linnea Skogtvedt
Mike Gabriel
* URL :
https://code.it-zukunft-schule.de/cgit/standardskriver/about/
* License : GPL-2+
Programming Lang: Python3
Description : Tool for dynamically setting a user's default printer at
desktop session logon
The Standard Skriver Tool ('standardskriver' is Norwegian, i.e. Bokmål,
for "default printer") allows the site admin to dynamically update
a user's default printer setting at logon time.
.
At desktop session startup, a new default printer gets automatically
configured based on the localation of the client host in use and/or also
based on POSIX group memberships of the current user.
.
Standard Skriver uses an easy-to-setup INI configuration file. The
configuration syntax also supports for configuring of multiple sites, so
one configuration file can be deployed to multiple sites.
.
The package will be maintained in the Debian Edu context.
Re: Corruption in CPU
On Tue, 27 Jun 2017, Armin Avdic wrote:
> Hello, I saw your article on corrupted data and I have reason to believe
> that the bad code goes as far back to Intel Pentium D processors, in my
The Intel Pentium D is a very old processor, and its hyper-threading is
very different from the recent processors. It cannot be the same
defect.
> investigation I have seen that when hyperthreading is disabled the cpu acts
> ok no corrupted data or corrupted downloads however when enabled the
> corrupted data starts showing up and changing md5 completely.
We do ship some public microcode updates for several Pentium D
processors, but they're really old updates. There is no guarantee that
they will fix your issue.
Note that it could be a problem elsewhere. Those are old processors, in
old motherboards, with old system components (memory, power supplies,
etc). And the current software (kernel, etc) is not often tested on
them anymore, so it could be a software problem, too.
If you want to try, please install intel-microcode as described in
https://wiki.debian.org/Microcode
Pentium D specification updates ("defect list"):
https://www.intel.com/content/www/us/en/support/processors/desktop-processors/07016.html
http://www.intel.com/content/dam/support/us/en/documents/processors/pentiumd/sb/310307.pdf
http://www.intel.com/content/dam/support/us/en/documents/processors/pentiumd/sb/306832.pdf
--
Henrique Holschuh
Re: Corruption in CPU
Thanks, I'll check it out.
On 27 Jun 2017 16:32, "Henrique de Moraes Holschuh" wrote:
> On Tue, 27 Jun 2017, Armin Avdic wrote:
> > Hello, I saw your article on corrupted data and I have reason to believe
> > that the bad code goes as far back to Intel Pentium D processors, in my
>
> The Intel Pentium D is a very old processor, and its hyper-threading is
> very different from the recent processors. It cannot be the same
> defect.
>
> > investigation I have seen that when hyperthreading is disabled the cpu
> acts
> > ok no corrupted data or corrupted downloads however when enabled the
> > corrupted data starts showing up and changing md5 completely.
>
> We do ship some public microcode updates for several Pentium D
> processors, but they're really old updates. There is no guarantee that
> they will fix your issue.
>
> Note that it could be a problem elsewhere. Those are old processors, in
> old motherboards, with old system components (memory, power supplies,
> etc). And the current software (kernel, etc) is not often tested on
> them anymore, so it could be a software problem, too.
>
> If you want to try, please install intel-microcode as described in
> https://wiki.debian.org/Microcode
>
> Pentium D specification updates ("defect list"):
> https://www.intel.com/content/www/us/en/support/processors/
> desktop-processors/07016.html
> http://www.intel.com/content/dam/support/us/en/documents/
> processors/pentiumd/sb/310307.pdf
> http://www.intel.com/content/dam/support/us/en/documents/
> processors/pentiumd/sb/306832.pdf
>
> --
> Henrique Holschuh
>
Re: Intended MBF: maintainer scripts not using strict mode
Ralf Treinen writes: > On Mon, Jun 26, 2017 at 11:09:26PM +0200, Mattia Rizzolo wrote: >> sigh. >> And using `#!/bin(ba)?sh -e` is not good either (there is a lintian tag >> about it, iirc). > what is the rationale for this? Is anyone calling maintainer scripts > like "sh
Re: Intended MBF: maintainer scripts not using strict mode
On Tue, Jun 27, 2017 at 09:03:16AM +0200, Ralf Treinen wrote: > On Mon, Jun 26, 2017 at 11:09:26PM +0200, Mattia Rizzolo wrote: > > On Mon, Jun 26, 2017 at 10:23:56PM +0200, Ralf Treinen wrote: > > > we currently have in sid 84 maintainer scripts not using strict mode. > > > That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e". > > > The list is attached. This list includes the 12 remaining scripts not > > > starting on #! (bugs are already filed for these). > > sigh. > > And using `#!/bin(ba)?sh -e` is not good either (there is a lintian tag > > about it, iirc). > what is the rationale for this? Is anyone calling maintainer scripts > like "sh
Subject: UMASK 002 or 022?
I'd like to know why giving the world (Other) read access is even under consideration. If user wants a file to have Other readability this should be on the user to set it, but it should not be the default. What is the justification that every user be able to read everyone else's documents? This discussion should be on whether to set a default UMASK of 077 or 027. NOTE: this discussion is moot at the present time anyway because it is impossible to set a UMASK at all on Debian Stretch. None of the usual ways work within gnome on Debian Stretch. Can anyone comment on this fact?
Replacing apt's http method (dropping curl)
Hi everyone,
as we discussed before in IRC, we plan to eventually replace
our existing curl-based https method with our http method,
by adding TLS support to it. This will move HTTPS support
into apt proper, removing the apt-transport-https package.
I'm not sure how long this will take, I hope we get something
useful next month.
Rationale
=
* The https method is split out of apt because curl has a lot
of dependencies (29 vs 7 on my test setup, 15.9 vs 4 MB of
disk space)
* We want https to be a default these days, even if it provides
only minor security improvements.
* Our http method is actually tested a lot because it is the
default and supports advanced features, the https method just
does curl easy stuff sequentially.
Transition plan
===
I plan to do this in two stages, both of which I expect to
happen in unstable if all features have been implemented
quickly. There might be feature-incomplete alphas in
experimental.
In the first stage, the "https" method is renamed to
"https+curl", and a https->http symlink is added in apt.
If no significant regressions are reported (we might drop
some options or increase some checks), and the package has
been in testing for some time, the apt-transport-https
package is removed.
This ensures that (a) we get proper testing and (b) users
have a workaround if something fails in that testing period.
Implementation
==
I so far implemented basic https support using GnuTLS, including
SNI and certificate validation, and one (!) local CA file (as our
tests need that). The code is incredibly hacky right now. And
https->http redirects don't work yet.
Alternatives would be to use libnss or openssl. In the latter
case, we'd have to build a separate helper binary that does not
link to the GPLed code, and just unwraps a TLS connection into
a pipe (similar to stunnel) - we could also use a helper generally,
it would allow us to run the TLS stack as nobody (!!!) [OK,
we have to open the socket in the parent process and pass it
down to the TLS stack, so _apt opens the connection for firewalls].
The existing shitty proof of concept is available on GitHub:
https://github.com/Debian/apt/compare/master...julian-klode:feature/http-https?expand=1
But as I said it's ugly. It also does not yet link the http
binary to the https binary.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Re: Intended MBF: maintainer scripts not using strict mode
Hello, On Mon, Jun 26, 2017 at 10:23:56PM +0200, Ralf Treinen wrote: > we currently have in sid 84 maintainer scripts not using strict mode. > That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e". Thanks to everybody for your feedback. I guess I will stick with severity=normal for the moment. The MBF template, list of offending maintainer scripts, and dd-list are attached. -Ralf. Dear maintainer, at least one of the maintainer scripts (preinst, postinst, prerm, postrm) of the package #PACKAGE# does not use strict mode. Policy section 10.4 says: Shell scripts (sh and bash) [..] should almost certainly start with set -e so that errors are detected. Every script should use set -e or check the exit status of every command. Please insert a "set -e" at the beginning of your script to enable strict mode. You should not replace this by a first line "#!/bin/sh -e" as it is not effective when your script is executed by an explicit invocation of sh. Note that this might make your script fail in cases where it did not fail before. This is the purpose of strict mode - make it fail when any unexpected error is encountered. You should make sure that you catch any error (non-zero exit codes of commands) that you decide to tolerate. Techniques to locally catch an error include using appropriate options to your command when available, adding a " || true" at the end of the command, or selectively switching off strict mode by "set +e" and switching it back on again later by "set -e". This bug filing has been discussed and approved in thread [1]. -Ralf. [1] https://lists.debian.org/debian-devel/2017/06/msg00342.html asterisk-prompt-de_2.0-1.1/preinst authbind_2.1.2/postinst authbind_2.1.2/prerm bcache-tools_1.0.8-2+b1/preinst bible-kjv_4.29+b1/postinst bible-kjv_4.29+b1/postrm bible-kjv_4.29+b1/prerm bible-kjv-text_4.29/postinst bible-kjv-text_4.29/prerm bind9_1:9.10.3.dfsg.P4-12.3/postrm binfmtc_0.17-2+b1/postinst binfmtc_0.17-2+b1/postrm bwbar_1.2.3-2.1+b2/prerm ca-certificates-mono_4.6.2.7+dfsg-1/postinst checksecurity_2.0.16+nmu1/preinst clips_6.24-3.2/postinst cxref_1.6e-2+b1/postrm debbugs_2.4.1.1/postrm debfoster_2.7-2.1+b1/postrm discover_2.1.2-7.1/postrm discover_2.1.2-7.1/preinst dsh_0.25.10-1.3/postinst dsh_0.25.10-1.3/postrm dsh_0.25.10-1.3/preinst dvifb_1:01.03-14.2/postinst dvifb_1:01.03-14.2/postrm geki3_1.0.3-8.1/postinst geki3_1.0.3-8.1/postrm gjiten_2.6-3/postinst gnukhata-core-engine_2.6.1-3/postrm golang-godebiancontrol-dev_0.0~git20140119-1/preinst guidedog_1.2.0-3+b1/postrm hyperspec_1.30+nmu2/postinst kterm_6.2.0-46.2/postinst kterm_6.2.0-46.2/prerm ldp-docbook-xsl_0.0.20040321-3/preinst ldp-docbook-xsl_0.0.20040321-3/prerm libclips_6.24-3.2/postinst libclips_6.24-3.2/prerm linpac_0.24-1+b1/postrm logtool_1.2.8-10/postrm logtool_1.2.8-10/preinst lpr_1:2008.05.17.2+b1/postinst lpr_1:2008.05.17.2+b1/postrm manpages-posix-dev_2013a-2/postinst manpages-posix-dev_2013a-2/postrm manpages-posix-dev_2013a-2/preinst mgetty-docs_1.1.36-3/preinst mgetty-fax_1.1.36-3+b1/preinst mgetty-voice_1.1.36-3+b1/postrm mime-support_3.60/prerm pmw-doc_1:4.29-1/postinst pmw-doc_1:4.29-1/preinst python-imaging-doc-html_1.1.2-1.2/postinst python-imaging-doc-pdf_1.1.2-1.2/postinst python-kde4_4:4.14.3-2/postinst remembrance-agent_2.12-7+b2/prerm samba_2:4.6.5+dfsg-2/prerm samba-common-bin_2:4.6.5+dfsg-2/prerm samhain_4.1.4-2/preinst sauce_0.9.0+nmu3/postrm scalable-cyrfonts-tex_4.17/postinst scalable-cyrfonts-tex_4.17/postrm scanlogd_2.2.5-3.3/postinst scanlogd_2.2.5-3.3/postrm scanlogd_2.2.5-3.3/prerm sendfile_2.1b.20080616-5.3+b3/preinst simba_0.8.4-4.3/postrm spacearyarya_1.0.2-7.1/postinst spacearyarya_1.0.2-7.1/postrm suricata_4.0.0-beta1-1~exp1/preinst swapspace_1.10-4+b2/postinst t1-cyrillic_4.17/postrm t1-oldslavic_4.17/postinst t1-oldslavic_4.17/postrm t1-teams_4.17/postinst t1-teams_4.17/postrm websimba_0.8.4-4.3/postinst websimba_0.8.4-4.3/postrm whizzytex_1.3.2-1.3/prerm wodim_9:1.1.11-3+b2/preinst Adam Majer lpr Andreas Barth mgetty Andreas Barth debfoster (U) Andrew Bartlett samba (U) Anton Zinoviev scalable-cyrfonts Antonio Cardoso Martins guidedog Ardo van Rangelrooij ldp-docbook-stylesheets (U) Arturo Borrero Gonzalez suricata (U) Balasankar C gnukhata-core-engine Botond Botyanszki gjiten Camm Maguire cxref Charles Plessy mime-support (U) Colin Tuckley linpac (U) Colin Watson debbugs (U) David Mohr bcache-tools David Nusinow discover (U) Debbugs developers debbugs debfoster Maintainer Team debfoster Debian Common Lisp Team hyperspec Debian Games Team geki3 spacearyarya Debian Hamradio Maintainers linpac Debian Install System Team discover Debian Mono Group mono Debian Qt/KDE Maintainers pykde4 Debian Samba Maintainers samba Debian XML/SGML Group ldp-docbook-stylesheets Don Armstrong debbugs (U) Eduard Bloch cdrkit (U) Eugene V. Ly
Re: Replacing apt's http method (dropping curl)
On Wed, Jun 28, 2017 at 2:00 AM, Julian Andres Klode wrote: > Hi everyone, > > as we discussed before in IRC, we plan to eventually replace > our existing curl-based https method with our http method, > by adding TLS support to it. This will move HTTPS support > into apt proper, removing the apt-transport-https package. > > I'm not sure how long this will take, I hope we get something > useful next month. > Great stuff! > > Implementation > == > I so far implemented basic https support using GnuTLS, including > SNI and certificate validation, and one (!) local CA file (as our > tests need that). The code is incredibly hacky right now. And > https->http redirects don't work yet. > I think this shouldn't work (at least by default). If https->http happens silently (not dying with an error or requiring a force option), that would make degradation happen while users think they are using HTTPS properly. Regards, Aron
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
Hello, On Tue, Jun 27, 2017 at 09:37:01AM +0200, Florian Weimer wrote: > > On Mon, 2017-06-26 at 08:34 +, Holger Levsen wrote: > > Other procesors aren't bug-free, they just don't get as many bug fixes. > > And the fixes aren't documented publicly at all. Similar to the time I was affected by problems with all Intel s3610 and s3710 SSDs which they spent a few weeks denying existed and then said was fixed in a firmware update whose release notes do not mention the issue. When pressed as to the details of the fix they just apologised and said that there hadn't been time to include mention of the problem in the release notes. Not even one line. https://communities.intel.com/thread/77801?start=15&tstart=0 It was a big hit to my trust in Intel and I stopped buying s3610 SSDs after this, but I don't expect other manufacturers are any better. Cheers, Andy
Re: Replacing apt's http method (dropping curl)
On 6/27/17 2:00 PM, Julian Andres Klode wrote: > Hi everyone, > > as we discussed before in IRC, we plan to eventually replace > our existing curl-based https method with our http method, > by adding TLS support to it. This will move HTTPS support > into apt proper, removing the apt-transport-https package. > > I'm not sure how long this will take, I hope we get something > useful next month. > > Rationale > = > * The https method is split out of apt because curl has a lot > of dependencies (29 vs 7 on my test setup, 15.9 vs 4 MB of > disk space) > * We want https to be a default these days, even if it provides > only minor security improvements. > * Our http method is actually tested a lot because it is the > default and supports advanced features, the https method just > does curl easy stuff sequentially. > > Transition plan > === > I plan to do this in two stages, both of which I expect to > happen in unstable if all features have been implemented > quickly. There might be feature-incomplete alphas in > experimental. > > In the first stage, the "https" method is renamed to > "https+curl", and a https->http symlink is added in apt. > > If no significant regressions are reported (we might drop > some options or increase some checks), and the package has > been in testing for some time, the apt-transport-https > package is removed. > > This ensures that (a) we get proper testing and (b) users > have a workaround if something fails in that testing period. > > Implementation > == > I so far implemented basic https support using GnuTLS, including > SNI and certificate validation, and one (!) local CA file (as our > tests need that). The code is incredibly hacky right now. And > https->http redirects don't work yet. > > Alternatives would be to use libnss or openssl. In the latter > case, we'd have to build a separate helper binary that does not > link to the GPLed code, and just unwraps a TLS connection into > a pipe (similar to stunnel) - we could also use a helper generally, > it would allow us to run the TLS stack as nobody (!!!) [OK, > we have to open the socket in the parent process and pass it > down to the TLS stack, so _apt opens the connection for firewalls]. > > The existing shitty proof of concept is available on GitHub: > > https://github.com/Debian/apt/compare/master...julian-klode:feature/http-https?expand=1 > > But as I said it's ugly. It also does not yet link the http > binary to the https binary. > This may not be the place or time to ask this but will https work with apt-cacher-ng? Most caches just pass the data through them and can't store the original files like apt-cacher-ng can. Would the local machines connect to ap-acacher-ng over http and apt-cacher-ng connect to the debian mirrors using https? Or could the apt-cacher-ng install generate a local certificate that the local machines could be set to accept as a valid debian cache/mirror and have apt-cacher-ng use https to the debian mirrors? ...Bob
Re: Replacing apt's http method (dropping curl)
On Wed, Jun 28, 2017 at 03:42:14AM +0800, Aron Xu wrote:
> On Wed, Jun 28, 2017 at 2:00 AM, Julian Andres Klode wrote:
> > Hi everyone,
> >
> > as we discussed before in IRC, we plan to eventually replace
> > our existing curl-based https method with our http method,
> > by adding TLS support to it. This will move HTTPS support
> > into apt proper, removing the apt-transport-https package.
> >
> > I'm not sure how long this will take, I hope we get something
> > useful next month.
> >
>
> Great stuff!
>
> >
> > Implementation
> > ==
> > I so far implemented basic https support using GnuTLS, including
> > SNI and certificate validation, and one (!) local CA file (as our
> > tests need that). The code is incredibly hacky right now. And
> > https->http redirects don't work yet.
> >
>
> I think this shouldn't work (at least by default). If https->http
> happens silently (not dying with an error or requiring a force
> option), that would make degradation happen while users think they are
> using HTTPS properly.
Sorry, I of course meant: Does not fail correctly. It just hangs. I'm
currently rewriting the stuff, the second version should be cleaner and
hopefully fix this issue.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Re: IMPORTANT: Do live Debian images have a future?
Charles, let me clear up a couple of misconceptions for you. Debian Live (made with Live Wrapper) is an official Debian project. Live Build (the old Debian Live) apparently wasn't official but was recognised by Debian for its official images. Live Build is now officially part of Debian and Rafael Hertzog is the new developer maintainer of Live Build. As for reporting bugs because Debian Live (that uses Live Wrapper) is an official Debian project bugs should be reported through the bug tracker. That is the way it has been since Live Wrapper was first released. However people still do, and I have done it also, report issues with Live Wrapper in the Live mailing list. Hope that helps. On 27 June 2017 at 21:54, Charles Chambers wrote: > And I'll add my 2¢ as an end user. > > The live images exist IMHO to test compatibility before committing to > installation, and to install what was just tested and demonstrated, > regardless of environment. It's a nice feature (arguably an essential > feature) that the actual install mirror *exactly* the tested compatibility > and appearance. To go with this, it *was* nice to be able to install in > the absence of a network connection or Internet service. > > The Live environment still works fine for testing for compatibility, > especially when the Nonfree repository is included. Installation, no > longer. > > My 2¢ is that installation suffers from a lack of testing, probably > because Debian Live is a "unofficial" branch off the development tree. > It's made worse because bugs for Live have no clear reporting process. > Where DOES one report a problem - to this mailing list, or the mailing list > more obviously suited (think a bug found while installing...report here, or > report to debian-install, or to debian-boot)? > > Inquiring minds want to know! > > Charlie > > > > On Jun 26, 2017 12:55 PM, "Michael ." wrote: > >> I'm not a dev but I am a user and I do test so I'll add my bit here. >> >> Let's be frank Live Wrapper only exists because of animosity within >> Debian towards the originator of Live Build (and to be honest his own lack >> of concern for what Debian required of Live Build). Live Wrapper was rushed >> and was never going to be ready for Stretch and in hindsight it was a >> little foolish to think it would be ready to build the types of images >> Debian required. Live Build wasn't up to scratch but the UEFI support issue >> has been fixed so what other issues are there with Live Build that makes it >> unreasonable to use? >> >> On 27 June 2017 at 00:08, Steve McIntyre wrote: >> >>> [ Note the cross-posting... ] >>> >>> Hey folks, >>> >>> Background: we released live images for Stretch using new tooling, >>> namely live-wrapper. It is better than what we had before (live-build) >>> in a number of ways, particularly in terms of build reliability and >>> some important new features (e.g. UEFI support). But it's also less >>> mature and has seen less testing. There have been bugs because of >>> that. I have fixes for most of the ones I know about [1], and I'm >>> still working on more bugfixes yet. >>> >>> While the bugs are annoying, what worries me more is that they were >>> only spotted in release builds. There had been testing versions of >>> live images available for multiple weeks beforehand, presumably with >>> the same bugs included. (Almost) none of them reported. This shows >>> that we don't have enough people using these live images and/or caring >>> about filing bugs. >>> >>> We have a similar lack of involvement in terms of the content of the >>> live images. As I said above, I'm happy that we now have a reliable >>> tool for building our live images - that makes my life much >>> easier. But I honestly have no idea if the multiple desktop-specific >>> live images are actually reasonable representations of each of the >>> desktops. For example, I *seriously* hope that normal KDE >>> installations are not effected by #865382 like our live KDE >>> images. Validation by the various desktop teams would be useful here. >>> >>> The current situation is *not* good enough. I ended up getting >>> involved in live image production because the images needed making, >>> and I was already the main person organising production of Debian's >>> official images. To be frank, I had (and still have) no direct use for >>> the live images myself and I don't *particularly* care about them all >>> that much. Despite that, I've ended up spending a lot of time working >>> on them. A few other people have also spent a lot of time working in >>> this area - thanks are due to those people too. But it's still not >>> enough. >>> >>> If our live images are going to be good enough to meet the standards >>> that Debian users deserve and expect, we need *consistent*, >>> *sustained* involvement from a lot more people. Please tell me if >>> you're going to help. If we don't see a radical improvement soon, I'll >>> simply disable building live images altogether to remove the f
Re: Subject: UMASK 002 or 022?
On Wed, Jun 28, 2017 at 1:11 AM, gwmfms6 wrote: > I'd like to know why giving the world (Other) read access is even under > consideration. If user wants a file to have Other readability this should be > on the user to set it, but it should not be the default. I expect for most Debian deployments this isn't that relevant, since most are either servers with no real users or single-user systems with no guest account. > What is the justification that every user be able to read everyone else's > documents? This decision was made in the mists of time and has never been questioned. > This discussion should be on whether to set a default UMASK of 077 or 027. I think the appropriate default umask is 077 due to the possibility of some sites not naming the primary group of each user after the user. That said, 027 would probably be a reasonable default too since most sites do not do that. > NOTE: this discussion is moot at the present time anyway because it is > impossible to set a UMASK at all on Debian Stretch. None of the usual ways > work within gnome on Debian Stretch. Can anyone comment on this fact? I had "UMASK 027" in /etc/login.defs and I didn't notice that this no longer works because I also run `umask 027` from my shell configuration. If you can track down why this no longer works, please file a bug about it and convince the maintainer to fix it in stretch. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Replacing apt's http method (dropping curl)
On Wed, Jun 28, 2017 at 2:00 AM, Julian Andres Klode wrote:
> Hi everyone,
>
> as we discussed before in IRC, we plan to eventually replace
> our existing curl-based https method with our http method,
> by adding TLS support to it. This will move HTTPS support
> into apt proper, removing the apt-transport-https package.
>
> I'm not sure how long this will take, I hope we get something
> useful next month.
>
> Rationale
> =
> * The https method is split out of apt because curl has a lot
> of dependencies (29 vs 7 on my test setup, 15.9 vs 4 MB of
> disk space)
> * We want https to be a default these days, even if it provides
> only minor security improvements.
> * Our http method is actually tested a lot because it is the
> default and supports advanced features, the https method just
> does curl easy stuff sequentially.
>
> Transition plan
> ===
> I plan to do this in two stages, both of which I expect to
> happen in unstable if all features have been implemented
> quickly. There might be feature-incomplete alphas in
> experimental.
>
> In the first stage, the "https" method is renamed to
> "https+curl", and a https->http symlink is added in apt.
>
I'd guess you have to help process the bootstrap process.
The TLS stuff is a quilt big trouble when bootstrap Debian for new
architecture.
So, I prefer the current schema, aka split https stuff to itself's
source package.
> If no significant regressions are reported (we might drop
> some options or increase some checks), and the package has
> been in testing for some time, the apt-transport-https
> package is removed.
>
> This ensures that (a) we get proper testing and (b) users
> have a workaround if something fails in that testing period.
>
> Implementation
> ==
> I so far implemented basic https support using GnuTLS, including
> SNI and certificate validation, and one (!) local CA file (as our
> tests need that). The code is incredibly hacky right now. And
> https->http redirects don't work yet.
>
> Alternatives would be to use libnss or openssl. In the latter
> case, we'd have to build a separate helper binary that does not
> link to the GPLed code, and just unwraps a TLS connection into
> a pipe (similar to stunnel) - we could also use a helper generally,
> it would allow us to run the TLS stack as nobody (!!!) [OK,
> we have to open the socket in the parent process and pass it
> down to the TLS stack, so _apt opens the connection for firewalls].
>
> The existing shitty proof of concept is available on GitHub:
>
> https://github.com/Debian/apt/compare/master...julian-klode:feature/http-https?expand=1
>
> But as I said it's ugly. It also does not yet link the http
> binary to the https binary.
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
> | Ubuntu Core Developer |
> When replying, only quote what is necessary, and write each reply
> directly below the part(s) it pertains to ('inline'). Thank you.
>
--
YunQiang Su
Re: Subject: UMASK 002 or 022?
Paul Wise writes: > On Wed, Jun 28, 2017 at 1:11 AM, gwmfms6 wrote: >> NOTE: this discussion is moot at the present time anyway because it is >> impossible to set a UMASK at all on Debian Stretch. None of the usual ways >> work within gnome on Debian Stretch. Can anyone comment on this fact? > > I had "UMASK 027" in /etc/login.defs and I didn't notice that this no > longer works because I also run `umask 027` from my shell > configuration. If you can track down why this no longer works, please > file a bug about it and convince the maintainer to fix it in stretch. It doesn't work since pam_umask isn't run by default. However as far as I know this has been the case for a very long time (the oldest install I can check quickly is squeeze and it has the same issue). -- Arto Jantunen
Re: Replacing apt's http method (dropping curl)
On Wed, Jun 28, 2017 at 12:40:16PM +0800, YunQiang Su wrote:
> I'd guess you have to help process the bootstrap process.
> The TLS stuff is a quilt big trouble when bootstrap Debian for new
> architecture.
> So, I prefer the current schema, aka split https stuff to itself's
> source package.
It's already in the same source package, we just strictly
reduce build-depends, so things can't get worse.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
