Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
Source: openssl Version: 1.1.0f-5 Severity: serious Hello Kurt, I looked back at the debian-devel discussion and it seems to me that the majority of persons who expressed themselves (including Moritz Mühlenhoff of the Debian security team) believe that buster should ship with TLS 1.0 and TLS 1.1 enabled. Given this, I would like to request you to make sure that Debian testing has a version of openssl with TLS 1.0 and TLS 1.1 enabled. The rough consensus seems to be that it's ok for you to use Debian unstable as a test-bed for your experiment to disable TLS 1.0 and TLS 1.1. While that might not be practical to manage when you have to push an update to testing, it's a burden that you should accept since you believe that Debian experimental will not give enough exposure. Please do listen to your fellow developers. Thank you. Cheers, PS: I'm filing this because I would like to not have to fork OpenSSL for Kali. It's counter-productive to go too fast in deprecating old protocols. You will only get less users using the official Debian package with all the risks it involves. Or at least I would like a system-wide flag (in a configuration file?) to let me re-enable old protocols easily. -- System Information: Debian Release: buster/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#875427: ITP: mailman3-django -- A common django base of tools for Mailman3's frontends Postorius and HyperKitty
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= * Package name: mailman3-django Version : 1.1.0 Upstream Author : Aurélien Bompard * URL : http://list.org/ * License : GPLv3 Programming Lang: Python Description : A common django base of tools for Mailman3's frontends Postorius and HyperKitty This package contains libraries and templates for Django-based interfaces interacting with Mailman. In particular, it provides a common base for Postorius and HyperKitty to work. -- This package is a necessary dependency to close bugs #799287 and #799285. I'm working on these packages with Mattia Rizzolo (mattia), Barry Warsaw (barry), and quite recently, Jonas Meurer (mejo) offered his help. -- PEB
Bug#875432: ITP: python3-sphinx-intl -- translation support utility for Sphinx
Package: wnpp Severity: wishlist Owner: Hideki Yamane * Package name: python3-sphinx-intl Version : 0.9.9 Upstream Author : Takayuki SHIMIZUKAWA * URL : https://github.com/sphinx-doc/sphinx-intl * License : BSD-2-Clause Programming Lang: Python Description : translation support utility for Sphinx sphinx-intl is a utility tool that provides several features that make it easy to translate and to apply translation to Sphinx generated document. . (Optional: support the Transifex service for translation with Sphinx)
Re: Steps towards a patch to document disabling a daemon upon installation
Sean Whitton writes ("Steps towards a patch to document disabling a daemon upon
installation"):
...
> [draft policy text]
...
> > +The default behaviour is to enable autostarting your package's daemon.
> > +If the daemon should not be autostarted unless the local administrator
> > +has explicitly requested this, use instead add to your ``postinst``
> > +script
> > +
> > +::
> > +
> > +update-rc.d package defaults
> > +update-rc.d package disable
This has a bug: after the first rune, but before this second, starting
the daemon is enabled. (This is a regression compared to the previous
approach.)
To make this work correctly, I think we need a new update-rc.d
mechanism which provides, in one go, the equivalent of
update-rc.d DAEMON defaults && update-rc.d DAEMON disable
Something like
update-rc.d DAEMON add-disabled
maybe.
> > +An older practice, which should not be used, was to include a line
> > +like ``DISABLED=yes`` in the package's ``/etc/default`` file. The
> > +package's init script would not start the service until the local
> > +system administrator changed this to ``DISABLED=no``, or similar.
...
> 1. Is the 'should not' for the /etc/default practice too strong? I
>don't know an efficient way to find out how many packages this would
>make buggy. But given that we have very strong reasons against the
>old practice, we might want to use a 'should not' regardless.
On sysvinit systems, using update-rc.d disable/defaults are rather
more awkward:
* Enabling and disabling cannot, in practice, be conveniently made
without using the update-rc.d tool.
* Enabling and disabling generates a tremendous amount of noise in
/etc (especially visible when using etckeeper).
> 2. Do we need to include any text saying *why* the /etc/default practice
>is a bad idea? I couldn't come up with a succinct way to state it.
>In general, I think we can err on the side of not including the text,
>since we have policy bugs that document the reasons.
How about this text:
Setting a value in /etc/default/PACKAGE is nowadays troublesome
because supporting that pattern is very hard due to inflexibility in
systemd, which is usually the default init system.
This also makes it clear that this pattern is perfectly fine if for
any reason the package does not support systemd.
> 3. The maintscript snippet I have added is not right because it will
>disable the daemon every time the package is updated. Unfortunately,
>the postinst doesn't know whether this is a new installation, or an
>upgrade.
This should also be fixed with a new update-rc.d rune.
>I looked at dh_installinit(8) and update-rc.d(8) and I couldn't get
>them to generate a postinst that does what I want. It seems you're
>expected to use all three of these:
>
>dh_systemd_enable --no-enable
>dh_systemd_start --no-start
>dh_installinit --no-start
>
>but then after a reboot, a sysvinit system will start the daemon,
>AFAICT.
I can't speak to the behaviour of systemd, but I think the
update-rc.d add-disabled
operation I propose would, for sysvinit systems, do the follow:
1. Are there already rc*.d links for DAEMON ? If so, do nothing.
2. If not, create them in the way that defaults && disable
would have done.
Ian.
Why small "Uncompressed Size: 2,048" for ssmtp
Hi, I am wondering what makes aptitude screen to print: Compressed Size: 54.2 k Uncompressed Size: 2,048 Source Package: ssmtp for ssmtp package. Uncompressed size is usually bigger than compressed Size. Am I missing something. INFO file in the ssmtp deb package has: new debian package, version 2.0. size 54172 bytes: control archive=17623 bytes. 58 bytes, 2 lines conffiles 1082 bytes,64 lines * config #!/bin/sh 940 bytes,21 lines control 2312 bytes,96 lines * postinst #!/bin/sh 362 bytes,26 lines * postrm #!/bin/sh 367 bytes,21 lines * preinst #!/bin/sh 38672 bytes, 317 lines templates Package: ssmtp Source: ssmtp (2.64-8) Version: 2.64-8+b2 Architecture: amd64 Maintainer: Anibal Monsalve Salazar Installed-Size: 2 This 2 is in KB. iConsistent with aptitude but why so small??? Any idea? Osamu
Re: Why small "Uncompressed Size: 2,048" for ssmtp
Osamu Aoki writes ("Why small "Uncompressed Size: 2,048" for ssmtp"):
> I am wondering what makes aptitude screen to print:
> Compressed Size: 54.2 k
> Uncompressed Size: 2,048
> Source Package: ssmtp
> for ssmtp package.
>
> Uncompressed size is usually bigger than compressed Size.
> Am I missing something.
...
> Source: ssmtp (2.64-8)
> Version: 2.64-8+b2
> Architecture: amd64
> Maintainer: Anibal Monsalve Salazar
> Installed-Size: 2
>
> This 2 is in KB. iConsistent with aptitude but why so small???
This is clearly due to some kind of bug. The actual installed size is
much bigger. The "Installed-Size" field is wrong.
I suggest you:
1. Check the bugs against dpkg-dev
2. Try rebuilding it from source and see if that reproduces the bug
3. If so, file a bug against the dpkg-dev package
If rebuilding it produces a correct package with a plausible
Installed-Size, then we need to investigate how the anomalous binary
was generated.
The i386 package has the same problem so perhaps we could find a
.buildinfo to say what the build environment was.
When we know the cause we'll probably want to schedule rebuilds of
affected packages.
Ian.
Re: Why small "Uncompressed Size: 2,048" for ssmtp
Hi, On 11/09/17 15:11, Osamu Aoki wrote: > I am wondering what makes aptitude screen to print: > Compressed Size: 54.2 k > Uncompressed Size: 2,048 > Source Package: ssmtp > for ssmtp package. > > Uncompressed size is usually bigger than compressed Size. > Am I missing something. > > INFO file in the ssmtp deb package has: > > new debian package, version 2.0. > size 54172 bytes: control archive=17623 bytes. > 58 bytes, 2 lines conffiles > 1082 bytes,64 lines * config #!/bin/sh > 940 bytes,21 lines control > 2312 bytes,96 lines * postinst #!/bin/sh > 362 bytes,26 lines * postrm #!/bin/sh > 367 bytes,21 lines * preinst #!/bin/sh >38672 bytes, 317 lines templates > Package: ssmtp > Source: ssmtp (2.64-8) > Version: 2.64-8+b2 > Architecture: amd64 > Maintainer: Anibal Monsalve Salazar > Installed-Size: 2 > > This 2 is in KB. iConsistent with aptitude but why so small??? The debian/rules file calls dpkg-gencontrol before installing anything, so dpkg-gencontrol doesn't "see" any of the binaries when calculating the installed size. https://sources.debian.net/src/ssmtp/2.64-8/debian/rules/ Maybe it should start using debhelper... James signature.asc Description: OpenPGP digital signature
Re: Why small "Uncompressed Size: 2,048" for ssmtp
On Mon, Sep 11, 2017 at 03:20:36PM +0100, James Cowgill wrote: > Maybe it should start using debhelper... yes, please. -- cheers, Holger signature.asc Description: Digital signature
s/python3-sphinx-intl/sphinx-intl
Please consider changing the source package name to sphinx-intl. Based on the description of the source package, it will produce a stand-alone utility not a Python library. Cheers, Ghis
Re: Why small "Uncompressed Size: 2,048" for ssmtp
James Cowgill writes ("Re: Why small "Uncompressed Size: 2,048" for ssmtp"):
> The debian/rules file calls dpkg-gencontrol before installing anything,
> so dpkg-gencontrol doesn't "see" any of the binaries when calculating
> the installed size.
>
> https://sources.debian.net/src/ssmtp/2.64-8/debian/rules/
*splorf*
Sorry for my mail which was pointing in the wrong direction. I should
have UTSL.
Ian.
Bug#875475: ITP: eyebrowse-el -- simple-minded way of managing window configs in Emacs
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: eyebrowse-el Version : 0.7.5 Upstream Author : Vasilij Schneidermann * URL or Web page : https://github.com/wasamasa/eyebrowse * License : GPL-3+ Programming Lang: Emacs Lisp Description : simple-minded way of managing window configs in Emacs This package provides a global minor mode for Emacs that allows one to manage window configurations in a simple manner, just like tiling window managers like i3wm with their workspaces do. It displays their current state in the modeline by default. The behaviour is modeled after ranger, a file manager written in Python.
Bug#875486: ITP: golang-blitiri-go-log -- Simple logging library in Go
Package: wnpp Severity: wishlist Owner: Alberto Bertogli * Package name: golang-blitiri-go-log Version : 0.0~git20170910.0.2b2e1b6-1 Upstream Author : Alberto Bertogli * URL : https://blitiri.com.ar/git/r/log/ * License : MIT (Expat) Programming Lang: Go Description : Simple logging library in Go blitiri.com.ar/go/log is a Go package implementing a simple logger. It implements an API somewhat similar to glog, with a focus towards simplicity and integration with standard tools such as systemd. This will soon be a dependency for package "chasquid".
Bug#875490: ITP: golang-blitiri-go-spf -- SPF (Sender Policy Framework) implementation in Go
Package: wnpp Severity: wishlist Owner: Alberto Bertogli * Package name: golang-blitiri-go-spf Version : 0.0~git20170821.0.33aa985-1 Upstream Author : Alberto Bertogli * URL : https://blitiri.com.ar/git/r/spf/ * License : MIT (Expat) Programming Lang: Go Description : SPF (Sender Policy Framework) implementation in Go blitiri.com.ar/go/spf is an open source implementation of the Sender Policy Framework (SPF) in Go. It is used by the chasquid SMTP server (package "chasquid"), and will soon be a dependency of it.
Bug#875493: ITP: patroni -- Template for PostgreSQL High Availability
Package: wnpp Severity: wishlist Owner: Michael Banck * Package name: patroni Version : 1.3.4 Upstream Author : Alexander Kukushkin Feike Steenbergen Oleksii Kliukin * URL : https://github.com/zalando/patroni * License : MIT Programming Lang: Python Description : Template for PostgreSQL High Availability Patroni is a template for a customized, high-availability PostgreSQL solution using Python and a distributed configuration store (ZooKeeper, etcd or Consul). It provides a REST API on each Postgres node of the cluster allowing for remote management and monitoring.
Bug#875489: ITP: golang-blitiri-go-systemd -- Utilities to interact with systemd sockets in Go
Package: wnpp Severity: wishlist Owner: Alberto Bertogli * Package name: golang-blitiri-go-systemd Version : 0.0~git20170821.0.aec3508-1 Upstream Author : Alberto Bertogli * URL : https://blitiri.com.ar/git/r/systemd/ * License : MIT (Expat) Programming Lang: Go Description : Utilities to interact with systemd sockets in Go systemd is a Go package implementing a way to get network listeners from systemd, similar to C's sd_listen_fds() and sd_listen_fds_with_names(). Supports named file descriptors, which is useful if your daemon needs to be able to tell the different ports apart (e.g. http vs https). It can be used by daemons to listen on privileged ports without needing to run as root. This will soon be a dependency for package "chasquid".
Re: Steps towards a patch to document disabling a daemon upon installation
On Mon, 11 Sep 2017 14:41:12 +0100, Ian Jackson wrote:
> Sean Whitton writes ("Steps towards a patch to document disabling a
> daemon upon installation"):
> ...
>> [draft policy text]
> ...
>> > +The default behaviour is to enable autostarting your package's
>> > daemon.
>> > +If the daemon should not be autostarted unless the local
>> > administrator +has explicitly requested this, use instead add to your
>> > ``postinst`` +script +
>> > +::
>> > +
>> > +update-rc.d package defaults +update-rc.d package disable
>
> This has a bug: after the first rune, but before this second, starting
> the daemon is enabled. (This is a regression compared to the previous
> approach.)
>
> To make this work correctly, I think we need a new update-rc.d mechanism
> which provides, in one go, the equivalent of
> update-rc.d DAEMON defaults && update-rc.d DAEMON disable
>
> Something like
> update-rc.d DAEMON add-disabled
> maybe.
FWIW, there's a bug for that: #857452
>> 2. Do we need to include any text saying *why* the /etc/default
>> practice
>>is a bad idea? I couldn't come up with a succinct way to state it.
>>In general, I think we can err on the side of not including the
>>text,
>>since we have policy bugs that document the reasons.
>
> How about this text:
>
> Setting a value in /etc/default/PACKAGE is nowadays troublesome
> because supporting that pattern is very hard due to inflexibility in
> systemd, which is usually the default init system.
>
> This also makes it clear that this pattern is perfectly fine if for any
> reason the package does not support systemd.
The /etc/default/PACKAGE thing was an anti-pattern before systemd
appeared, so gratuitous jabs at it are out of place. I suggest instead
mentioning the real reasons its bad:
1. Two interfaces for disabling services, which is confusing. All init
systems already have an interface to disable services, so it is better to
use that instead.
2. Nonstandard interface: is the knob called DISABLE or ENABLE? Is it
ENABLE_FOO or ENABLE_BAR? Or maybe BAR_ENABLED? Since the pattern is
reinvented by different services there is inconsistency.
3. Confusing and incorrect bootup messages. "Foo doesn't work even though
I see that it starts at boot!"
4. Inability to start disabled services. A service with ENABLE=no can't
be started without editing the default file, and then you have to
remember to set it back before reboot.
>
>> 3. The maintscript snippet I have added is not right because it will
>>disable the daemon every time the package is updated.
>>Unfortunately,
>>the postinst doesn't know whether this is a new installation, or an
>>upgrade.
>
> This should also be fixed with a new update-rc.d rune.
Agreed.
> I can't speak to the behaviour of systemd, but I think the
>
> update-rc.d add-disabled
>
> operation I propose would, for sysvinit systems, do the follow:
>
> 1. Are there already rc*.d links for DAEMON ? If so, do nothing.
>
> 2. If not, create them in the way that defaults && disable
> would have done.
Currently, update-rc.d leaves all the hard work to insserv under sysvinit.
The behaviour would have to change to check if any links exist and skip
invoking insserv in that case. I am not sure if that would mean a behavior
change though. Maybe this early in the release cycle is a good time to
try these kinds of changes.
For systemd, this operation would be a nop. I don't know about other init
systems. What would they need?
--
Saludos,
Felipe Sateler
ITP: golang-github-moul-http2curl -- Go package for convert Golang's http.Request to CURL command line
Package: wnpp Severity: wishlist Owner: Nobuhiro Iwamatsu * Package name: golang-github-moul-http2curl Version : 0.0~git20161031.0.4e24498-1 Upstream Author : Manfred Touron * URL : https://github.com/moul/http2curl * License : Expat Programming Lang: Go Description : Go package for convert Golang's http.Request to CURL command line Package http2curl provides the function to convert Golang's http.Request to CURL command line. By setting the URL, argument, Content-Type, output the command line to be executed with CURL.
Bug#875545: ITP: cpdf -- The tool provide a wide range of professional, robust tools to modify PDF files.
Package: wnpp Severity: wishlist Owner: Francisco Vilmar Cardoso Ruviaro * Package name: cpdf Version : 2.2.1 Upstream Author : John Whitington * URL : https://github.com/johnwhitington/cpdf-source * License : Coherent Graphics Ltd Non-Commercial Use License Programming Lang: OCaml Description : The tool provide a wide range of professional, robust tools to modify PDF files. The tool provide a wide range of facilities for modifying PDF files created by other means. There is a single command-line program cpdf.
Re: Bug#875545: ITP: cpdf -- The tool provide a wide range of professional, robust tools to modify PDF files.
On Tue, Sep 12, 2017 at 01:40:08AM -0300, Francisco Vilmar Cardoso Ruviaro wrote: > * License : Coherent Graphics Ltd Non-Commercial Use License This is suitable only for non-free, and only if this is acceptable: 2. The Coherent Graphics Ltd is granted back, without any restrictions or limitations, a non-exclusive, perpetual, irrevocable, royalty-free, assignable and sub-licensable license to reproduce, perform or display, install, use, modify, post, distribute, make and have made, sell and transfer your modifications to and/or derivative works of the Software source code or data, for any purpose. > Description : The tool provide a wide range of professional, robust > tools to modify PDF files. The description should be improved. -- WBR, wRAR signature.asc Description: PGP signature
