Re: OpenSSL disables TLS 1.0 and 1.1

[Marco d'Itri]

On Aug 09, Sven Hartge  wrote:

> Looking at https://developer.android.com/about/dashboards/index.html
> there is still a marketshare of ~25% of smartphones based on Android 5.0
> and 5.1 and 16% based on 4.4. So this change would (at the moment) block
> ~40% of Android smartphones from connecting to any WLAN using PEAP or
> TTLS.
Android 5.x should support TLS 1.2:
http://caniuse.com/#search=TLS

but I see on your link that Android pre-5.x still has a ~25% market 
share, so unless it will drop a lot in the next year I do not think that 
we can cut them off from Debian-based web servers.
Everybody please remember that our own personal hardware is not 
representative of the market... :-)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: OpenSSL disables TLS 1.0 and 1.1

[Sven Hartge]

Marco d'Itri  wrote:
> On Aug 09, Sven Hartge  wrote:

>> Looking at https://developer.android.com/about/dashboards/index.html
>> there is still a marketshare of ~25% of smartphones based on Android
>> 5.0 and 5.1 and 16% based on 4.4. So this change would (at the
>> moment) block ~40% of Android smartphones from connecting to any WLAN
>> using PEAP or TTLS.

> Android 5.x should support TLS 1.2:
> http://caniuse.com/#search=TLS

The Browser, yes. But not the components doing the WPA stuff:

,
| Aug  9 20:09:13 ds9 radiusd[4179992]: (12924) Login incorrect (eap_ttls: TLS 
Alert write:fatal:protocol version): [owehxperia] (from client ap01 port 54 cli 
30-39-26-xx-xx-xx)
| Aug  9 20:09:24 ds9 radiusd[4179992]: (12928) eap_ttls: ERROR: TLS Alert 
write:fatal:protocol version
| Aug  9 20:09:24 ds9 radiusd[4179992]: tls: TLS_accept: Error in error
`

Only recompiling openssl with TLS1.0 and TLS1.1 enabled allowed my phone
to connect successfully.

> but I see on your link that Android pre-5.x still has a ~25% market 
> share, so unless it will drop a lot in the next year I do not think that 
> we can cut them off from Debian-based web servers.

It is far more than 25%. Lollipop, Kitkat and Jelly Bean add up to ~52%
of marketshare and I don't think this number will drop significantly
below 25% in the next 2 to 3 years.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Let's enable AppArmor by default (why not?)

[Wouter Verhelst]

On Sun, Aug 06, 2017 at 01:27:49PM +0500, Andrey Rahmatullin wrote:
> On Sun, Aug 06, 2017 at 07:28:08AM +, Dr. Bas Wijnen wrote:
> > I can't think of a situation where you would not want it
> The "I don't want yet another thing that can cause subtle breakages and
> doesn't give me anything" situation (see disabling selinux after install
> on RH systems).

It actually does give you anything, and debugging SELinux breakages is
fairly simple, with the fix usually being rather small.

For a while after RedHat started enabling SELinux by default on their
systems, a number of security researchers yelled "I've found an
exploitable bug in RedHat" for which the first step to exploit was
always "first, disable SELinux". I'm not saying that that's not a
problem, but it *does* show that using SELinux or AppArmor has benefits.

I think enabling an LSM by default is a good idea, and we should do it
if we can. The "subtle breakages" you mention are annoying for you, but
they can be a showstopper for an attacker, and that's a *good* thing.
Yes, obviously when we enable an LSM we should also make it easy for
users to understand that something is blocked by the LSM and explain to
them how they can unblock it if they want to. But just saying "it causes
issues, let's not" is the same as saying "permissions on the file system
causes issues, let's install to FAT32 everywhere", and that's just not a
good idea.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: OpenSSL disables TLS 1.0 and 1.1

[Wouter Verhelst]

On Mon, Aug 07, 2017 at 08:35:52PM +0200, Kurt Roeckx wrote:
> On Mon, Aug 07, 2017 at 05:22:51PM +0200, Joerg Jaspert wrote:
> > I wonder if there is a middle way that ensures that all new stuff does
> > go TLS1.2 (or later, whenever), but does allow older stuff still to
> > work. Which isnt the case if they are just disabled.
> 
> I could change the default settings to set the minimum supported
> version as TLS 1.2. That is, act like
> SSL_CTX_set_min_proto_version() was called with TLS1_2_VERSION.
> That would allow applications to override this this by calling
> SSL_CTX_set_min_proto_version(). But then those are new
> functions in 1.1.0 and they probably aren't supported by many
> applications.
> 
> An other alternative is to use the deprecated SSL_CTX_set_options
> options (SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1) by default, but then
> there is probably no software that has support for clearing those
> with SSL_CTX_clear_options()

Would it instead be possible to create an item in the openssl.conf file
to disable TLS1.2 by default? That way, users can re-enable TLS1.{0,1}
in cases where that's required, and you can drop TLS1.0 and 1.1 (and
possibly 1.2 even, if 1.3 has enough traction) in bullseye.

Thanks,

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: OpenSSL disables TLS 1.0 and 1.1

[Marco d'Itri]

On Aug 11, Marco d'Itri  wrote:

> but I see on your link that Android pre-5.x still has a ~25% market 
> share, so unless it will drop a lot in the next year I do not think that 
> we can cut them off from Debian-based web servers.
OTOH if the PCI council says that TLS < 1.2 has to go by june 2018 then 
this will probably not be such a big deal:

https://www.fastly.com/blog/phase-two-our-tls-10-and-11-deprecation-plan/

But as it has been noted there is more than HTTP, so totally removing 
support for 1.0/1.1 may still not be appropriate.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: OpenSSL disables TLS 1.0 and 1.1

[Sven Hartge]

Marco d'Itri  wrote:
> On Aug 11, Marco d'Itri  wrote:

>> but I see on your link that Android pre-5.x still has a ~25% market
>> share, so unless it will drop a lot in the next year I do not think
>> that we can cut them off from Debian-based web servers.

> OTOH if the PCI council says that TLS < 1.2 has to go by june 2018
> then this will probably not be such a big deal:

> https://www.fastly.com/blog/phase-two-our-tls-10-and-11-deprecation-plan/

> But as it has been noted there is more than HTTP, so totally removing 
> support for 1.0/1.1 may still not be appropriate.

Not everything is regulated by the PCI council.

If, after upgrading to Buster, suddenly 25% of the students of my
university can no longer connect to the wireless network, it will be
hell on earth for me and my support staff.

It is nice to say "well, then get the other side to upgrade to a new
device", but as it has already been said in this discussion: The real
world does not work that way.

Unless it has been proven that TLS1.0 and TLS1.1 are as broken as SSL3,
please keep the support for them enabled in OpenSSL, and just change the
defaults in the application to only use TLS1.2 (unless changed by the
administrator).

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Bug#871781: ITP: shimdandy -- Shim wrapping multiple Clojure runtimes into the same JVM

[Tom Marble]

Package: wnpp
Severity: wishlist
Owner: Tom Marble 

* Package name: shimdandy
  Version : 1.2.0
  Upstream Author : Toby Crawley
* URL : https://github.com/projectodd/shimdandy
* License : EPL
  Programming Lang: Java
  Description : Shim wrapping multiple Clojure runtimes into the same JVM

A Clojure runtime shim, allowing for multiple Clojure runtimes in the same JVM.

Clojure has a static runtime (implemented as static methods off of
clojure.lang.RT), so to run multiple runtimes in the same JVM, they
have to be loaded in isolated ClassLoader trees. ShimDandy provides a
mechanism for isolating the runtimes within a non-Clojure application,
and for calling in to the runtimes from the app.

This library is a dependency for the Clojure build tool 'boot'
and will be maintained by the Debian Java Team.

Re: OpenSSL disables TLS 1.0 and 1.1

[Kurt Roeckx]

On Fri, Aug 11, 2017 at 01:34:53PM +0200, Sven Hartge wrote:
> Marco d'Itri  wrote:
> > On Aug 09, Sven Hartge  wrote:
> 
> >> Looking at https://developer.android.com/about/dashboards/index.html
> >> there is still a marketshare of ~25% of smartphones based on Android
> >> 5.0 and 5.1 and 16% based on 4.4. So this change would (at the
> >> moment) block ~40% of Android smartphones from connecting to any WLAN
> >> using PEAP or TTLS.
> 
> > Android 5.x should support TLS 1.2:
> > http://caniuse.com/#search=TLS
> 
> The Browser, yes. But not the components doing the WPA stuff:
> 
> ,
> | Aug  9 20:09:13 ds9 radiusd[4179992]: (12924) Login incorrect (eap_ttls: 
> TLS Alert write:fatal:protocol version): [owehxperia] (from client ap01 port 
> 54 cli 30-39-26-xx-xx-xx)
> | Aug  9 20:09:24 ds9 radiusd[4179992]: (12928) eap_ttls: ERROR: TLS Alert 
> write:fatal:protocol version
> | Aug  9 20:09:24 ds9 radiusd[4179992]: tls: TLS_accept: Error in error
> `
> 
> Only recompiling openssl with TLS1.0 and TLS1.1 enabled allowed my phone
> to connect successfully.

Any idea if this actually works with newer android phones?

Could someone report this to Google? I consider everything broken
by this a security issue and hope that Google will fix it in all
releases they still support.


Kurt

Re: OpenSSL disables TLS 1.0 and 1.1

[Christian Seiler]

Hi,

Am 2017-08-11 15:09, schrieb Sven Hartge:

Unless it has been proven that TLS1.0 and TLS1.1 are as broken as SSL3,
please keep the support for them enabled in OpenSSL, and just change 
the

defaults in the application to only use TLS1.2 (unless changed by the
administrator).


I remember a talk at Debconf15 about Fedora's system-wide policy for
Crypto stuff:

https://summit.debconf.org/debconf15/meeting/252/enforcement-of-a-system-wide-crypto-policies/

I haven't rewatched the talk, but if I remember correctly, the
whole thing was designed in a way that the administrator could
change both the system-wide policy and also override it per
application.

If we follow through on this, we could then disable anything but
TLS 1.2 in the default system-wide policy - the default settings
would then be more secure while users could then still change the
policy for compatibility reasons if so required. It would also
provide a central nob for the future for users who don't have to
worry about compatibility and perhaps want to disable TLS 1.2 in
favor of 1.3 (which will be part of OpenSSL 1.1.1).


Btw. speaking of this issue: a friend of mine who's an administrator
at a university has had the problem that he can't use the HTTPS
interface of some NAS devices (and I'm talking 19" rack-mounted
storage with internal and external SAS interface) anymore since the
interface only supports either older SSL versions or older ciphers
that modern browsers simply don't accept anymore. (Not even with
about:config options.) And there are no firmware updates for these
devices anymore, so he's now administering these devices via
unencrypted HTTP. Which is definitely worse than HTTPS with even
SSLv3. In his case it's not too bad, because they are in a separate
network that isn't routed to the public (using ssh -D to a gateaway
to access them), but this shows what problems can arise from this.

Don't get me wrong: I do believe it's a huge problem that vendors
of said appliances don't provide updates for these kind of things,
and I wish that we could indeed drop everything except TLS 1.2, but
the real world is unfortunately more complicated, and I think
Debian would do a huge disservice to users if it removed TLS 1.0
and 1.1 from OpenSSL in Buster without a well-documented
possibility for the admin to reenable it.

Regards,
Christian

Re: OpenSSL disables TLS 1.0 and 1.1

[Kurt Roeckx]

On Fri, Aug 11, 2017 at 08:41:10AM -0400, Wouter Verhelst wrote:
> On Mon, Aug 07, 2017 at 08:35:52PM +0200, Kurt Roeckx wrote:
> > On Mon, Aug 07, 2017 at 05:22:51PM +0200, Joerg Jaspert wrote:
> > > I wonder if there is a middle way that ensures that all new stuff does
> > > go TLS1.2 (or later, whenever), but does allow older stuff still to
> > > work. Which isnt the case if they are just disabled.
> > 
> > I could change the default settings to set the minimum supported
> > version as TLS 1.2. That is, act like
> > SSL_CTX_set_min_proto_version() was called with TLS1_2_VERSION.
> > That would allow applications to override this this by calling
> > SSL_CTX_set_min_proto_version(). But then those are new
> > functions in 1.1.0 and they probably aren't supported by many
> > applications.
> > 
> > An other alternative is to use the deprecated SSL_CTX_set_options
> > options (SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1) by default, but then
> > there is probably no software that has support for clearing those
> > with SSL_CTX_clear_options()
> 
> Would it instead be possible to create an item in the openssl.conf file
> to disable TLS1.2 by default? That way, users can re-enable TLS1.{0,1}
> in cases where that's required, and you can drop TLS1.0 and 1.1 (and
> possibly 1.2 even, if 1.3 has enough traction) in bullseye.

I prefer this to be enabled on application basis, which is why I
suggested the above ways.

OpenSSL has support for setting such a mimimum in a config file,
I'm just not sure if it reads any section related to it by
default, I think it doesn't.


Kurt

Re: Better infrastructure for dbgsyms

[Bastien ROUCARIES]

On Thu, Aug 10, 2017 at 9:56 PM, Niels Thykier  wrote:
> Stefan Fritsch:
>> Hi,
>>
>> [...]
>>
>
> Hi,
>
> Thanks for improving dbgsym integration. :)
>
>> BTW, in some discussions some other questions were raised:
>>
>> - Is it really a good idea that foo-dbgsym depends on "foo (==
>> foo-version)"? Wouldn't a Conflict or breaks on "foo (!= foo-version)"
>> make more sense respective package? Consider that you want to analyze the
>> core dump on a different system and foo may pull in quite a lot of
>> dependencies, start servers, etc.
>>
>
>  could be debugging coredumps from multiple versions on the same
> machine.  As a debugger, you are basically interested in the
> /usr/lib/debug files themselves and not the dbgsym.deb.
>   The .deb packages happen to be the only transport mechanism that
> Debian provides, but we should consider that they limit people to
> basically debugging on the same distribution as they are running  (at
> least if you want to dbg files for libc and other low level libraries).
>
> Anyway, The relation was added for two reasons:
>
>  * It was a "requirement" imposed to me when I wrote it from several
>others.  I presume that it was historical to match that of -dbg
>packages
>
>  * To make dbgsym packages trivially policy compliant (without
>duplicating the copyright file), I used usr/share/doc symlinks.

Do you link the doc dir or only the copyright file ? if it is a dir it
will be a mess (see dpkg-maintscript-helper symlinktodir)

BTW do we have created a depends ddeb-support (=version) ? If no do we
have a plan of how to change format ?

The = depends ease transition also. So I want to have the point of
view of release team about this

>
>> - Is it allowed for packages that are not in the debug section to depend
>> on packages in the debug section. [...]
>>
>
> Not in Debian.  The "main" component of the "debian" archive is
> self-contained; the "debian-debug" archive is an add-on on top of this.
> By introducing a dependency from "debian" to "debian-debug", you would
> basically introduce a unsatisfiable dependency (for users, whom have not
> opted in to the "debian-debug" archive).
>
> Largely, it is the technically similar to a package in main depending on
> a package in non-free (except for the legal/ethical implications).
>
>> - Would an option to put all symbols from a source package into a single
>> dbgsym package make sense? This would allow to get rid of all those dbgsym
>> packages with only a single small file in them.
>>
>
> Technically, it should rather trivial if we ignore some corner cases.
> Notably, the dbgsym would no longer be (bit-for-bit) reproducible under
> "noX" profiles (that exclude packages).
>
> We might also have to replace the usr/share/doc symlink in favour of a
> real copyright file (or assume that dbgsym packages cannot contain
> copyrightable information / is not subject to license terms or define
> that they inherit their license information from $SOMEWHERE).
>
>> - Should we put the URL of the debug sym sources.list entry into the
>> release file of the non-debug sym section? That way, apt could determine
>> the location of the dbgsym packages by itself without having to edit
>> sources.list.
>>
>>
>> Cheers,
>> Stefan
>>
>
> I think that is an interesting idea and would go nicely hand in hand
> with the request for other mirror metadata in #761348 (like what is the
> base suite for "add-on suites" like experimental)
>
> Thanks,
> ~Niels
>

Re: OpenSSL disables TLS 1.0 and 1.1

[Wouter Verhelst]

On Fri, Aug 11, 2017 at 04:24:03PM +0200, Kurt Roeckx wrote:
> On Fri, Aug 11, 2017 at 08:41:10AM -0400, Wouter Verhelst wrote:
> > On Mon, Aug 07, 2017 at 08:35:52PM +0200, Kurt Roeckx wrote:
> > > On Mon, Aug 07, 2017 at 05:22:51PM +0200, Joerg Jaspert wrote:
> > > > I wonder if there is a middle way that ensures that all new stuff does
> > > > go TLS1.2 (or later, whenever), but does allow older stuff still to
> > > > work. Which isnt the case if they are just disabled.
> > > 
> > > I could change the default settings to set the minimum supported
> > > version as TLS 1.2. That is, act like
> > > SSL_CTX_set_min_proto_version() was called with TLS1_2_VERSION.
> > > That would allow applications to override this this by calling
> > > SSL_CTX_set_min_proto_version(). But then those are new
> > > functions in 1.1.0 and they probably aren't supported by many
> > > applications.
> > > 
> > > An other alternative is to use the deprecated SSL_CTX_set_options
> > > options (SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1) by default, but then
> > > there is probably no software that has support for clearing those
> > > with SSL_CTX_clear_options()
> > 
> > Would it instead be possible to create an item in the openssl.conf file
> > to disable TLS1.2 by default? That way, users can re-enable TLS1.{0,1}
> > in cases where that's required, and you can drop TLS1.0 and 1.1 (and
> > possibly 1.2 even, if 1.3 has enough traction) in bullseye.
> 
> I prefer this to be enabled on application basis, which is why I
> suggested the above ways.

Sure. If I read "man 5 config" correctly though, openssl should allow
per-application configuration file snippets to be read. A proper howto
page on the wiki or elsewhere could then explain users how they should
add such a snippet for their applications (and *only* for those
applications where it is required).

I'm afraid that if you leave this to application developers, some
applications will not do it, leading uninformed users to simply
recompile OpenSSL themselves (with TLS1.0 and TLS1.1 enabled), thereby
resulting in a system with reduced security for *all* applications,
rather than just the one where they need TLS1.0.

> OpenSSL has support for setting such a mimimum in a config file,
> I'm just not sure if it reads any section related to it by
> default, I think it doesn't.

That might be a good feature request then, I suppose.

Alternatively, you could make the default in the absense of any
configuration file be to *not* enable TLS1.2, but allow it to be enabled
by an openssl configuration change (which AIUI is not the current state
of affairs). That would work too.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: OpenSSL disables TLS 1.0 and 1.1

[Sven Hartge]

Kurt Roeckx  wrote:
> On Fri, Aug 11, 2017 at 01:34:53PM +0200, Sven Hartge wrote:
>> Marco d'Itri  wrote:
>>> On Aug 09, Sven Hartge  wrote:
 
>> >> Looking at https://developer.android.com/about/dashboards/index.html
>> >> there is still a marketshare of ~25% of smartphones based on Android
>> >> 5.0 and 5.1 and 16% based on 4.4. So this change would (at the
>> >> moment) block ~40% of Android smartphones from connecting to any WLAN
>> >> using PEAP or TTLS.
>> 
>> > Android 5.x should support TLS 1.2:
>> > http://caniuse.com/#search=TLS
>> 
>> The Browser, yes. But not the components doing the WPA stuff:
>> 
>> ,
>> | Aug  9 20:09:13 ds9 radiusd[4179992]: (12924) Login incorrect (eap_ttls: 
>> TLS Alert write:fatal:protocol version): [owehxperia] (from client ap01 port 
>> 54 cli 30-39-26-xx-xx-xx)
>> | Aug  9 20:09:24 ds9 radiusd[4179992]: (12928) eap_ttls: ERROR: TLS Alert 
>> write:fatal:protocol version
>> | Aug  9 20:09:24 ds9 radiusd[4179992]: tls: TLS_accept: Error in error
>> `
>> 
>> Only recompiling openssl with TLS1.0 and TLS1.1 enabled allowed my phone
>> to connect successfully.

> Any idea if this actually works with newer android phones?

It works with Android 6.0 on my tablet and with 7.1.1 on my newer phone.

> Could someone report this to Google? I consider everything broken by
> this a security issue and hope that Google will fix it in all releases
> they still support.

Given the track record of vendors of Android-based phones on shipping
*any* updates Google provides, I'd say the chance of those fixes
actually reaching the end-user are slim to none.

(My Samsung tablet for example got *two* updates in its whole 4 year
life span: one to 5.1 and one to 6.0. Monthy security fixes: none.)

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: OpenSSL disables TLS 1.0 and 1.1

[Sven Hartge]

Christian Seiler  wrote:

> Don't get me wrong: I do believe it's a huge problem that vendors of
> said appliances don't provide updates for these kind of things, and I
> wish that we could indeed drop everything except TLS 1.2, but the real
> world is unfortunately more complicated, and I think Debian would do a
> huge disservice to users if it removed TLS 1.0 and 1.1 from OpenSSL in
> Buster without a well-documented possibility for the admin to reenable
> it.

I'd go one step further and say that Debian would disqualify itself as a
distribution usable for any real world application.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Improvement of sensible-utils

[Bastien ROUCARIES]

Hi,

I have done some work for sensible-utils but I am a little stuck due
to lack of documentation/policy.

I want first to create desktop file for
sensible-editor/sensible-pager/sensible-browser in order to open from
firefox text file (fixing #780742).

The main problem is to exec this in a terminal or not depending of the context.

I propose first to solve #594942 and to implement sensible-x-terminal
first. This program will
exec $XTERMINAL if set, then if configured $SENSIBLE_XTERMINAL and
lastly choose the terminal according to desktop running (maybe using
xdg-open /proc/self/1 <

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

/me just realized he made a stupid mistake by grep'ing Packages instead
of Sources.

Approximate data based on grep'ing Sources:
- 452 teams maintaining packages in unstable
- 3 is the median number of packages maintained by a team
- 155 teams maintaining a single package


On Mon, Aug 07, 2017 at 04:48:54PM +0300, Adrian Bunk wrote:
> 
> Approximate data based on grep'ing Packages[1]:
> - 466 teams maintaining packages in unstable
> - 8 is the median number of packages maintained by a team
> - 73 teams maintaining a single package
> 
> A package with 500 LOC might have an own team:
> https://qa.debian.org/developer.php?email=hostname-de...@lists.alioth.debian.org
> 
> cu
> Adrian
> 
> [1] grep -Ei '^Maintainer.*(team|maintainer|lists.alioth.debian.org).*'

Re: OpenSSL disables TLS 1.0 and 1.1

[Marc Haber]

On Fri, 11 Aug 2017 18:20:22 +0200, Sven Hartge 
wrote:
>Christian Seiler  wrote:
>> Don't get me wrong: I do believe it's a huge problem that vendors of
>> said appliances don't provide updates for these kind of things, and I
>> wish that we could indeed drop everything except TLS 1.2, but the real
>> world is unfortunately more complicated, and I think Debian would do a
>> huge disservice to users if it removed TLS 1.0 and 1.1 from OpenSSL in
>> Buster without a well-documented possibility for the admin to reenable
>> it.
>
>I'd go one step further and say that Debian would disqualify itself as a
>distribution usable for any real world application.

What Sven says, yes.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Bug#871812: ITP: gajim-rostertweaks -- allows user to tweak Gajim roster window appearance

[W. Martin Borgert]

Package: wnpp
Severity: wishlist
Owner: Debian Gajim Maintainers 

* Package name: gajim-rostertweaks
  Version : 0.6.3
  Upstream Author : Denis Fomin 
* URL : 
https://dev.gajim.org/gajim/gajim-plugins/wikis/RosterTweaksPlugin
* License : GPL3+
  Programming Lang: Python
  Description : allows user to tweak Gajim roster window appearance

Allows user to tweak roster window appearance (eg. make it
compact). This is especially helpful for people running Gajim on
small screens, such as the PocketChip.

Re: OpenSSL disables TLS 1.0 and 1.1

[Russ Allbery]

Marco d'Itri  writes:

> But as it has been noted there is more than HTTP, so totally removing
> support for 1.0/1.1 may still not be appropriate.

Adding a data point here, my employer (Dropbox) is reasonably aggressive
about SSL configuration, but based on the usage we see, we've not yet been
comfortable with dropping TLS 1.0 and 1.1.  Maybe we will be by the end of
the buster release cycle, but that isn't entirely clear to me.  Google,
Amazon, Microsoft, and the EFF all also still support TLS 1.0/1.1 on their
primary web sites, for whatever that's worth.

A good external validation for when industry best practice is willing to
drop TLS 1.0/1.1 support is when Qualys SSL Labs
(https://www.ssllabs.com/ssltest/) starts lowering the grade below A+ for
sites that have TLS 1.0/1.1 enabled.  They still haven't been willing to
take that step, and I think they're a reasonable lagging indicator for
current accepted best SSL practice.

That doesn't mean we can't make it very easy to disable TLS 1.0/1.1 or
encourage people to do that when possible, of course.  It would be great
for us to try to lead the way and push things forward a bit.  But I think
we're still going to have to make it very easy to enable TLS 1.0/1.1 for a
lot of people and applications for a bit longer.

-- 
Russ Allbery (r...@debian.org)   

Re: Detached upstream signature and git packaging

[Tomasz Buchert]

On 02/08/17 21:54, Guido Günther wrote:
>
> [...]
>
> We could also store it in the upstream tag message when importing the
> tarball but having it on pristine-tar looks nicer. Will you file
> wishlist bug against pristine-tar?
> Cheers,
>  -- Guido

For those interested, the bug is https://bugs.debian.org/871809.

Tomasz


signature.asc
Description: PGP signature

Bug#871827: ITP: message-templ -- templates for Emacs message-mode

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: message-templ
  Version : 0.3.20161104
  Upstream Author : ARISAWA Akihiro 
* URL : git://pivot.cs.unb.ca/message-templ.git
* License : GPL-2+
  Programming Lang: Emacs Lisp
  Description : templates for Emacs message-mode

I intend to maintain this as part of pkg-emacsen.  David Bremner,
another team member, maintains it upstream, so it will be easy to
co-ordinate with upstream to fix bugs and make improvements.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#871830: ITP: pylci -- Python-based Linux Control Interface

[W. Martin Borgert]

Package: wnpp
Severity: wishlist
Owner: Python Applications Packaging Team 


* Package name: pylci
  Version : 2017-03-10
  Upstream Author : Pičugins Arsenijs
* URL : https://github.com/CRImier/pyLCI
* License : Apache 2.0
  Programming Lang: Python
  Description : Python-based Linux Control Interface

pyLCI is a simple control interface for embedded devices, such
as Raspberry Pi. It's using display and button shields to give
you a simple yet powerful interface.

This is needed e.g. for the ZeroPhone.