Call for testing: APT 1.5~alpha1/experimental
APT 1.5~alpha1 landed in experimental today(ish). It includes three
big changes (one of which, the new https support, is opt-in).
[ Changes to unauthenticated repositories ]
The security exception for apt-get to only raise warnings if it encounters
unauthenticated repositories in the "update" command is gone now, so that it
will raise errors just like apt and all other apt-based front-ends do since
at least apt version 1.3.
It is possible (but STRONGLY ADVISED AGAINST) to revert to the previous
behaviour of apt-get by setting the option
Binary::apt-get::Acquire::AllowInsecureRepositories "true";
See apt-secure(8) manpage for configuration details.
[ Experimental https support in http ]
The http method will eventually replace the curl-based https method, but for
now, this is an opt-in experiment that can be enabled by setting
Dir::Bin::Methods::https to "http". Known issues:
- We do not support HTTPS proxies yet
- We do not support proxying HTTPS connections yet (CONNECT)
- IssuerCert and SslForceVersion are unsupported
TLS code paths can be disabled by setting Acquire::AllowTLS to "false".
[ Release Info Changes ]
If values like Origin, Label, and Codename change in a Release file,
update fails, or asks a user (if interactive). Various
--allow-releaseinfo-change are provided for non-interactive use.
Please consider testing it. I'm especially interested in people
using client certificates or anything fancy with HTTPS that is not
listed in the known issues list.
It would be great if people knowledgeable
about https and TLS in general also had a look at how GnuTLS is used:
https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=2851ec6cf037d552118b885be0dd7796d74730c6
(I accidentally squashed a move of the SOCKS code in there, but
it should still be readable)
Thanks!
--
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: Declarative packaging (Was: Re: Intended MBF: maintainer scripts not using strict mode)
Paul Wise writes ("Re: Declarative packaging (Was: Re: Intended MBF: maintainer
scripts not using strict mode)"):
> IIRC last time we discussed this, the recommendation was to set an
> environment variable that maintainer scripts could check to determine
> if they should do host-specific actions or just generic actions common
> to all hosts. Personally I think that seems like a bit of a hack and
> there needs to be a new state for packages to be in added to dpkg.
How about using triggers-pending for this ?
You'd need to canonical trigger name.
Ian.
Re: IMPORTANT: Do live Debian images have a future?
On തിങ്കള് 26 ജൂണ് 2017 07:38 വൈകു, Steve McIntyre wrote: > 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 > I'd be happy to test and report bugs continuously. I have already started reporting some bugs. signature.asc Description: OpenPGP digital signature
Re: Intended MBF: maintainer scripts not using strict mode
Ralf Treinen writes: > I had a cursory look over the listed maintainer scripts, and did not > find any that does a careful checking of exit statuses. Though some > of them are quite trivial, or even sometimes empty. It looks to me > as not using strict mode in these cases is an oversight, and I would > like to file bugs for these. > > 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 think it would have been better to have: i) filed no more than 1 bug per source package ii) been specific about the scripts you were objecting to Regards, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Re: Intended MBF: maintainer scripts not using strict mode
On 27/06/17 18:47, Russ Allbery wrote: > 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: Call for testing: APT 1.5~alpha1/experimental
On Thu, Jun 29, 2017 at 09:38:31AM +0200, Julian Andres Klode wrote:
> APT 1.5~alpha1 landed in experimental today(ish). It includes three
> big changes (one of which, the new https support, is opt-in).
1.5~alpha2 fixes a critical security issue for people that set
a custom CaInfo option: Alpha 1 always loaded the system-wide CA
store, now only the custom one is loaded.
As another notable change, you can now use the http method for
tor+https, just set Dir::Bin::Methods::tor+https to "http".
Also SRV support now properly uses the port specified in the
SRV response, not the original port (there will be a stable
update for that).
--
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: UMASK 002 or 022?
The wider community doesn't seem that concerned with the fact that all Debian and Ubuntu users are now (with the most recent stable releases) completely unable to change their default umask (and further have a default setting that gives the world read access to all their documents). I think this needs to be viewed as a security issue. Even with the premise that the average Linux user is more computer competent than the average Windows or Mac user, I still don't think it's a fair assumption that all linux users know all about umask and permissions. Due to this, many users may unwittingly create "guest" accounts or friend accounts on their computers unknowingly giving read access to all documents they've created. This is not an uncommon practice in university contexts especially. Same goes if there's any sort of remote access going on through SSH etc. This issue strikes me as something that should be of higher concern to the community. Someone mentioned changing the permissions on one's home folder. That just adds insult to injury that by default everyone's home folder let's the world have read access along with all files being created with read access. It's poor privacy and security policy. The average computer-user assumes that other account holders can't read their "stuff" unless they do something to allow that person to read their stuff. But this is completely untrue on Debian Stretch and Ubuntu 17.04.
Work-needing packages report for Jun 30, 2017
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1079 (new: 1) Total number of packages offered up for adoption: 171 (new: 0) Total number of packages requested help for: 45 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: posterazor (#866220), orphaned yesterday Description: splits an image across multiple pages for assembly into a poster Installations reported by Popcon: 577 Bug Report URL: http://bugs.debian.org/866220 1078 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 171 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 211 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker openstack-pkg-tools Installations reported by Popcon: 838 Bug Report URL: http://bugs.debian.org/846328 balsa (#642906), requested 2104 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 668 Bug Report URL: http://bugs.debian.org/642906 busybox (#854181), requested 145 days ago Description: Tiny utilities for small and embedded systems Reverse Depends: bootcd busybox-syslogd dropbear-initramfs live-boot-initramfs-tools open-infrastructure-system-boot udhcpc udhcpd wicd-daemon zfs-initramfs Installations reported by Popcon: 199542 Bug Report URL: http://bugs.debian.org/854181 cargo (#860116), requested 79 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 477 Bug Report URL: http://bugs.debian.org/860116 cups (#532097), requested 2945 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client (66 more omitted) Installations reported by Popcon: 182439 Bug Report URL: http://bugs.debian.org/532097 cyrus-sasl2 (#799864), requested 645 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (127 more omitted) Installations reported by Popcon: 200818 Bug Report URL: http://bugs.debian.org/799864 dee (#831388), requested 349 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg libdee-dev zeitgeist-core Installations reported by Popcon: 66457 Bug Report URL: http://bugs.debian.org/831388 developers-reference (#759995), requested 1034 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 18548 Bug Report URL: http://bugs.debian.org/759995 devscripts (#800413), requested 639 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero bzr-builddeb customdeb debci debian-builder debmake debpear (24 more omitted) Installations reported by Popcon: 13176 Bug Report URL: http://bugs.debian.org/800413 ejabberd (#767874), requested 969 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml ejabberd-mod-message-log ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-pottymouth ejabberd-mod-rest (4 more omitted) Installations reported by Popcon: 629 Bug Report URL: http://bugs.debian.org/767874 fbcat (#565156), requested 2724 days ago Description: framebuffer grabber Installations reported by Popcon: 201 Bug Report URL: http://bugs.debian.org/565156 fgetty (#823061), requested 425 days ago Description: console-only getty & login (issue with nis) Installations reported by Popcon: 1641 Bug Report URL: http://bugs.debian.org/823061 freeipmi (#628062), requested 2226 days ago Description: GNU implementation
Re: UMASK 002 or 022?
On Thu, Jun 29, 2017 at 7:43 PM, wrote: > The wider community doesn't seem that concerned with the fact that all > Debian and Ubuntu users are now (with the most recent stable releases) > completely unable to change their default umask (and further have a default > setting that gives the world read access to all their documents). I think > this needs to be viewed as a security issue. > > Even with the premise that the average Linux user is more computer competent > than the average Windows or Mac user, I still don't think it's a fair > assumption that all linux users know all about umask and permissions. Due to > this, many users may unwittingly create "guest" accounts or friend accounts > on their computers unknowingly giving read access to all documents they've > created. This is not an uncommon practice in university contexts especially. > Same goes if there's any sort of remote access going on through SSH etc. > > This issue strikes me as something that should be of higher concern to the > community. > > Someone mentioned changing the permissions on one's home folder. That just > adds insult to injury that by default everyone's home folder let's the world > have read access along with all files being created with read access. It's > poor privacy and security policy. The average computer-user assumes that > other account holders can't read their "stuff" unless they do something to > allow that person to read their stuff. But this is completely untrue on > Debian Stretch and Ubuntu 17.04. > Are you saying that default permissions for home dirs in Debian is 755? -- darkestkhan -- Feel free to CC me. jid: darkestk...@gmail.com May The Source be with You.
