Bug#872695: ITP: caja-admin -- Add administrative actions to Caja's right-click menu
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: caja-admin Version : 0.0.1 Upstream Author : Sander Sweers * URL : https://github.com/infirit/caja-admin * License : GPL-3+ Programming Lang: Python Description : Add administrative actions to Caja's right-click menu Caja Admin is a simple Python extension for the Caja file manager that adds some administrative actions to the right-click menu: . - Open as Administrator: opens a folder in a new Caja window running with administrator (root) privileges. - Edit as Administrator: opens a file in a Pluma window running with administrator (root) privileges. - Run as Administrator: runs an executable file with administrator (root) privileges inside a MATE Terminal. . The package will be maintained under the umbrella of the Debian+Ubuntu MATE Packaging Team and it will finally be a substitute for caja-gksu.
Bug#872697: ITP: node-unicode-10.0.0 -- Unicode data for Node.js
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-unicode-10.0.0 Version : 0.7.4 Upstream Author : Mathias Bynens (https://mathiasbynens.be/) * URL : https://github.com/mathiasbynens/unicode-10.0.0 * License : Expat Programming Lang: JavaScript Description : Unicode data for Node.js JavaScript-compatible Unicode data. Arrays of code points, arrays of symbols, and regular expressions for Unicode v10.0.0’s categories, scripts, blocks, bidi, and other properties. . Node.js is an event-based server-side JavaScript engine. Cheers, Snark on #debian-js
Re: openssl/libssl1 in Debian now blocks offlineimap?
On Fri, Aug 18, 2017 at 10:07:49PM +0200, Tollef Fog Heen wrote: > ]] Adrian Bunk >... > The PCI consortium extended the deadline until June > 2018. Assuming that deadline holds, people with older machines will not > be able to access services such as online banking or pay online in > general. That's wrong. Think of the "TLS 1.2 not working with WPA" discussed earlier here that might still affect half a billion active Android devices at the buster release date.[1] The online banking app running on such a device will support TLS 1.2 The PayPal app currently requires Android >= 4.0.3, released in 2011. > ... but they're pragmatic. > As they write in their press release: “…in the field a lot of business > issues surfaced…” said Stephen Orfei, General Manager, PCI SSC. “We want > merchants protected against data theft but not at the expense of turning > away business, ... Corollary: It is permitted to run your online banking app on an Android device with a 5 year old firmware with no security updates ever available. >... > to make sure any users on platforms where support for that is > lacking get a proper notification and a chance to move to something > newer. >... Imagine Debian running on the AP providing the WiFi for a Cafe. What you are saying is that the staff working at the Cafe should explain to their customers that they have to buy a new phone if they want to use the WiFi. cu Adrian [1] I haven't investigated how widespread this specific problem actually is, or whether it can be mitigated - the point is that it is unrelated to TLS versions supported by PayPal or online banking apps running on the device -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: openssl/libssl1 in Debian now blocks offlineimap?
Adrian Bunk wrote: > [1] I haven't investigated how widespread this specific problem > actually is, or whether it can be mitigated - the point is that > it is unrelated to TLS versions supported by PayPal or online > banking apps running on the device I asked on the freeradius-users list, if there is an easy way to log the SSL/TLS version a client uses during the PEAP/TTLS handshake, to get a better understanding of the situation on my universities wireless networks, but unfortunately this was not easily possible. http://lists.freeradius.org/pipermail/freeradius-users/2017-August/088521.html It would be really interesting to gather some long term statistics about this to see a trend of the adoption of newer TLS versions over time. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: openssl/libssl1 in Debian now blocks offlineimap?
]] Adrian Bunk > On Fri, Aug 18, 2017 at 10:07:49PM +0200, Tollef Fog Heen wrote: > > ]] Adrian Bunk > >... > > The PCI consortium extended the deadline until June > > 2018. Assuming that deadline holds, people with older machines will not > > be able to access services such as online banking or pay online in > > general. > > That's wrong. I'm not sure which bit of the quoted text you think is wrong. > Think of the "TLS 1.2 not working with WPA" discussed earlier here that > might still affect half a billion active Android devices at the buster > release date.[1] > > The online banking app running on such a device will support TLS 1.2 Maybe, maybe not. Depending on how it's implemented, it's non-trivial to get TLS 1.2 support in there. Just doing HTTP or TLS yourself is easy enough, but if you want to use a webview, you're at the mercy of the TLS libs of the OS. > The PayPal app currently requires Android >= 4.0.3, released in 2011. I'd not be surprised if that gets bumped, but that's just my guess, I have no knowledge into what their actual plans are. [...] > >... > > to make sure any users on platforms where support for that is > > lacking get a proper notification and a chance to move to something > > newer. > >... > > Imagine Debian running on the AP providing the WiFi for a Cafe. > > What you are saying is that the staff working at the Cafe should explain > to their customers that they have to buy a new phone if they want to use > the WiFi. Why would that be the case? They're likely to just be using WPA2 or have an open network, neither of which require TLS. Arguing for keeping TLS 1.0 support means you're arguing for providing users with a default-insecure setup. In today's world, I think that's a pretty poor choice. Providing people with the possibility to fall back to less secure solutions sounds like a much better choice, just like it's possible to install an telnetd providing unencrypted logins, but it requires you to actively go out and install it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Call for volunteers: FTP Team
On Fri, Aug 18, 2017 at 07:16:38PM +0500, Andrey Rahmatullin wrote: > Several mails in this thread seem to assume that the main or even the only > job of the ftp team is processing the NEW queue. This is not true. What is IMHO really true is that all answers in the thread while being mostly funny and entertaining have not revealed any volunteer for the team that was rather asking for man power than for name suggestions. Kind regards Andreas, -- http://fam-tille.de
Bug#872722: ITP: node-foreground-child -- : helper for running a child process as a foreground process
Package: wnpp Severity: wishlist Owner: ro...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-foreground-child Version : 1.5.6 Upstream Author : Isaac Z. Schlueter (http://blog.izs.me/) * URL : https://github.com/tapjs/foreground-child#readme * License : ISC Programming Lang: JavaScript Description : helper running a child process as a foreground process This Node.js module emulate simple control group in pure javacript. It runs a child process as foreground process redirecting output to stdout and exiting main process as soon as child exist. . This module could be used for implementating TAP test for Node.js. . TAP is a simple text-based interface between testing modules implemented in many popular languages. . Node.js is an event-based server-side JavaScript engine.
Re: openssl/libssl1 in Debian now blocks offlineimap?
On Sun, Aug 20, 2017 at 01:51:16PM +0200, Tollef Fog Heen wrote: > ]] Adrian Bunk >... > > Think of the "TLS 1.2 not working with WPA" discussed earlier here that > > might still affect half a billion active Android devices at the buster > > release date.[1] > > > > The online banking app running on such a device will support TLS 1.2 > > Maybe, maybe not. Depending on how it's implemented, it's non-trivial > to get TLS 1.2 support in there. Just doing HTTP or TLS yourself is > easy enough, but if you want to use a webview, you're at the mercy of > the TLS libs of the OS. >... TLS 1.1 and 1.2 are supported for client sockets in Android since 2012. TLS 1.1 and 1.2 are enabled by default for client sockets in Android since 2014. In other words: When buster gets released, there will still be few hundred million Android devices in use that do support TLS 1.1 and 1.2 but have it disabled by default. If you are a bank, then using TLS 1.2 in your online banking app is not a problem on these devices. The situation can be less rosy when a user tries to open a link to https://www.debian.org in the default browser. The recent trend of using HTTPS everywhere has the nasty side effect of TLS 1.0 being mandatory for public parts of webservers for as long as users continue to use browsers that don't support anything more recent. Even a bank that might want/have to restrict the online banking part of their website to TLS 1.2 and secure ciphers will still have a huge commercial incentive to support everything no matter how weak for HTTPS access to the public parts of their website where they advertise their services to potential new customers. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Call for volunteers: FTP Team
Hi Andreas, > What is IMHO really true is that all answers in the thread while being > mostly funny and entertaining have not revealed any volunteer for the > team that was rather asking for man power than for name suggestions. I share your frustration. However, you will be heartened to learn that the FTP team have received a significant number of requests off-list. :) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#872732: ITP: wildfly-common -- Wildfly common utilities project
Package: wnpp Severity: wishlist Owner: Markus Koschany * Package name: wildfly-common Version : 1.2.0 Upstream Author : Red Hat Inc. * URL : http://wildfly.org/ * License : Apache-2.0 Programming Lang: Java Description : Wildfly common utilities project Wildfly is a Java application server which implements the Java Platform, Enterprise Edition (Java EE) specification. . This package contains common utilities to work with Wildfly applications. This package is a new build-dependency of jboss-xnio and will be maintained by the Java team.
Bug#872733: ITP: wildfly-client-config -- Wildfly Client Configuration Library
Package: wnpp Severity: wishlist Owner: Markus Koschany * Package name: wildfly-client-config Version : 1.0.0 Upstream Author : Red Hat Inc. * URL : http://wildfly.org/ * License : Apache-2.0 Programming Lang: Java Description : Wildfly Client Configuration Library Wildfly is a Java application server which implements the Java Platform, Enterprise Edition (Java EE) specification. This package contains Wildfly's client configuration library. This package is a new build-dependency of jboss-xnio and required to update the package to the latest version. It will be maintained by the Java team.
Single Sign On for Debian
Previous on mailinglist alioth-staff-replacem...@lists.alioth.debian.org IMHO is debian-devel@lists.debian.org a better place for this. - Forwarded message from Enrico Zini - Date: Sun, 20 Aug 2017 18:03:26 +0200 From: Enrico Zini To: alioth-staff-replacem...@lists.alioth.debian.org Cc: Geert Stappers Subject: Re: [Alioth-staff-replacement] Fwd: Re: Alioth needs your help User-Agent: NeoMutt/20170113 (1.7.2) > >> SSO doesn't have own backends. > > Isn't db.debian.org the backend that knowns about all DD? > > SSO, as it is right now, is NOT a user managing thing. SSO is ONLY > taking existing users from one or more (two right now, db.d.o/alioth) > backends, and allows them to have a single sign on on connected debian > services, nm.debian.org being the biggest of it, DebConf pages the next > one (that i know of). > > If someone is willing to invest the time and work to make SSO fly up and > be THE one point other things can connect to, meaning that it eats DD > data from db.d.o but does its own user management for non-DDs, and also > willing to maintain that over time - and then also add stuff like being > an ouath provider, SAML something, whatever those things are called by > now, so that applications/services can easily be connected to it - then > setups like gitlab/gitea/whatever can go and use it as a provider, and > not the other way round. > > I am pretty sure the current maintainers of sso would love to get help, > possibly to the point of being happy to entirely give it to someone who > really wants to invest the time and work, also i cant speak for them, so > talk to them for more. Hi there. I'm not on this list, keep me Cc-ed or add me to the list as you wish. I am currently the only maintainer of sso.d.o and I confirm what Ganneff said. Currently not only sso.d.o doesn't do any user database, but it also never sees the users' web password or alioth passwords. Authentication is delegated to apache's mod_ldap, and I just see what's in REMOTE_USER. A bug in my code, with the current setup, won't leak users' passwords no matter what. I'm happy to give up maintenance of sso.d.o entirely and I don't mind if it gets replaced with whatever makes sense. The current setup is the simplest and most secure setup I can think of that can be maintained by one person, relies on widespread and well tested code (except for the custom certificate generation interface) and can federate trivially. Note that it's security-sensitive code for which I don't even get code review of my commits, with the exception of some recent post-debconf review and feedback by paultag. However, if anyone takes sso.d.o over, and then at some point disappears, I will be the most affected, as a broken sso.debian.org means a broken nm.debian.org and contributors.debian.org and I am the person taking care for those, too. In fact, I got stuck with maintaining sso.debian.org because the other people involved pulled out and I needed to keep nm.debian.org running, so that scenario has happened before. If it happens again, depending on what sso.debian.org will have become, I might choose to take down nm.debian.org until someone else fixes sso.debian.org, instead of taking ownership of something I can't maintain. I understand that gitlab has its own user database / registration / password change infrastructure; if you want to use that, we can see how to make sso.debian.org authenticate to it. If instead you prefer to have sso.debian.org handle non-DD registration, it is doable: python3-django-registration exists and can be used, and gitlab can probably then consume the client certificates. Between the two options, I would imagine that the gitlab registration code is far more polished and well tested than python3-django-registration, so I would suggest to have people register on gitlab and then interface sso.debian.org with that. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini ___ Alioth-staff-replacement mailing list alioth-staff-replacem...@lists.alioth.debian.org https://lists.alioth.debian.org/mailman/listinfo/alioth-staff-replacement - End forwarded message - -- Groeten Geert Stappers -- Leven en laten leven signature.asc Description: Digital signature
Re: Single Sign On for Debian
On Sun, Aug 20, 2017 at 06:16:07PM +0200, Geert Stappers wrote: > > Previous on mailinglist > alioth-staff-replacem...@lists.alioth.debian.org > > IMHO is debian-devel@lists.debian.org a better place for this. > > > - Forwarded message from Enrico Zini - > > Date: Sun, 20 Aug 2017 18:03:26 +0200 From: Enrico Zini > To: > alioth-staff-replacem...@lists.alioth.debian.org Cc: Geert Stappers > Subject: Re: [Alioth-staff-replacement] Fwd: > Re: Alioth needs your help User-Agent: NeoMutt/20170113 (1.7.2) > > > >> SSO doesn't have own backends. > > > Isn't db.debian.org the backend that knowns about all DD? > > > > SSO, as it is right now, is NOT a user managing thing. SSO is ONLY > > taking existing users from one or more (two right now, > > db.d.o/alioth) backends, and allows them to have a single sign on on > > connected debian services, nm.debian.org being the biggest of it, > > DebConf pages the next one (that i know of). > > > > If someone is willing to invest the time and work to make SSO fly up > > and be THE one point other things can connect to, meaning that it > > eats DD data from db.d.o but does its own user management for > > non-DDs, and also willing to maintain that over time - and then also > > add stuff like being an ouath provider, SAML something, whatever > > those things are called by now, so that applications/services can > > easily be connected to it - then setups like gitlab/gitea/whatever > > can go and use it as a provider, and not the other way round. > > > > I am pretty sure the current maintainers of sso would love to get > > help, possibly to the point of being happy to entirely give it to > > someone who really wants to invest the time and work, also i cant > > speak for them, so talk to them for more. > > Hi there. I'm not on this list, keep me Cc-ed or add me to the list as > you wish. > > I am currently the only maintainer of sso.d.o and I confirm what > Ganneff said. > > Currently not only sso.d.o doesn't do any user database, but it also > never sees the users' web password or alioth passwords. Authentication > is delegated to apache's mod_ldap, and I just see what's in > REMOTE_USER. A bug in my code, with the current setup, won't leak > users' passwords no matter what. > > I'm happy to give up maintenance of sso.d.o entirely and I don't mind > if it gets replaced with whatever makes sense. The current setup is > the simplest and most secure setup I can think of that can be > maintained by one person, relies on widespread and well tested code > (except for the custom certificate generation interface) and can > federate trivially. > > Note that it's security-sensitive code for which I don't even get code > review of my commits, with the exception of some recent post-debconf > review and feedback by paultag. > > However, if anyone takes sso.d.o over, and then at some point > disappears, I will be the most affected, as a broken sso.debian.org > means a broken nm.debian.org and contributors.debian.org and I am the > person taking care for those, too. In fact, I got stuck with > maintaining sso.debian.org because the other people involved pulled > out and I needed to keep nm.debian.org running, so that scenario has > happened before. If it happens again, depending on what > sso.debian.org will have become, I might choose to take down > nm.debian.org until someone else fixes sso.debian.org, instead of > taking ownership of something I can't maintain. > > I understand that gitlab has its own user database / registration / > password change infrastructure; if you want to use that, we can see > how to make sso.debian.org authenticate to it. > > If instead you prefer to have sso.debian.org handle non-DD > registration, it is doable: python3-django-registration exists and can > be used, and gitlab can probably then consume the client certificates. > > Between the two options, I would imagine that the gitlab registration > code is far more polished and well tested than > python3-django-registration, so I would suggest to have people > register on gitlab and then interface sso.debian.org with that. As expressed during the DC17 DSA and Cloud BoFs, I'm in favour of two related but orthogonal things: 1 collapsing user management into a single user store (LDAP)** 2 introducing SAML or OIDC IdPs so that we can tie into AWS, Azure, and GCP SSO features 1 isn't necessarily a pre-requisite for 2 but the mishmash of processing we have Guest vs DM vs DD is fugly (let alone Alioth-type users). ** Not necessarily the opinion of all DSA team members. -- Luca Filipozzi
Bug#869908: relax dependency on faraday in gemspec
On Fri, Aug 18, 2017 at 07:50:44PM (+0530), Pirate Praveen wrote: > ruby-faraday-middleware 0.12.2-1 just uploaded to unstable. Thanks!! Seb signature.asc Description: PGP signature
Re: openssl/libssl1 in Debian now blocks offlineimap?
On Sun, Aug 20, 2017 at 01:51:16PM +0200, Tollef Fog Heen wrote: > Arguing for keeping TLS 1.0 support means you're arguing for providing > users with a default-insecure setup. No. Arguing for keeping TLS1.0 *enabled by default* does. But arguing for *allowing* it to be re-enabled (without requiring a recompile of OpenSSL), as opposed to the "it's not even compiled in" stuff that we're getting now, does not. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: New archive key for wheezy generated
2017-08-16 5:15 GMT-04:00 bogdan: > My name is bogdan .i need help. Please contact Debian user support for help: https://www.debian.org/support -- bye, pabs https://wiki.debian.org/PaulWise
Re: OpenSSL disables TLS 1.0 and 1.1
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. I have a patch for that at: https://github.com/openssl/openssl/pull/4128 I might upload this soon. The intention is still to ship Buster with TLS 1.0 and 1.1 completly disabled. Kurt
Re: openssl/libssl1 in Debian now blocks offlineimap?
> pretty poor choice. Providing people with the possibility to fall back > to less secure solutions sounds like a much better choice, just like Problem is, where is this possibility right now? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: OpenSSL disables TLS 1.0 and 1.1
> I might upload this soon. The intention is still to ship Buster > with TLS 1.0 and 1.1 completly disabled. Disabled by configuration or disabled by not compiling it in? It'd be nice if, after all this discussion, you stated clearly whether you plan to change something or not. Meaning, will we get a libssl version that allows older TLS version or do you flatly deny the need for it and keep libssl as is? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: OpenSSL disables TLS 1.0 and 1.1
On Sun, Aug 20, 2017 at 09:14:47PM +0200, Michael Meskes wrote: > > I might upload this soon. The intention is still to ship Buster > > with TLS 1.0 and 1.1 completly disabled. > > Disabled by configuration or disabled by not compiling it in? With "completly disabled" I mean at build time. > It'd be nice if, after all this discussion, you stated clearly whether > you plan to change something or not. Isn't that what I just did? Kurt
Re: OpenSSL disables TLS 1.0 and 1.1
>> It'd be nice if, after all this discussion, you stated clearly whether >> you plan to change something or not. > > Isn't that what I just did? No, not exactly. You stated what you want to do in *Buster*, but not whether it's supposed to stay broken all the way until then. I guess this email of yours does make it clear, though. I guess we should then move the discussion from "should libssl support TLS 1.0/1.1" to "how do we get a system again that works with the not-so-up-to-date rest of the world". At least I think our social contract demands we offer a *working*" ssl setup: ... We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. ... Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Single Sign On for Debian
On 2017-08-20 16:28:05, Luca Filipozzi wrote: > As expressed during the DC17 DSA and Cloud BoFs, I'm in favour of two > related but orthogonal things: > 1 collapsing user management into a single user store (LDAP)** > 2 introducing SAML or OIDC IdPs so that we can tie into AWS, Azure, and > GCP SSO features > > 1 isn't necessarily a pre-requisite for 2 but the mishmash of processing > we have Guest vs DM vs DD is fugly (let alone Alioth-type users). Looking at the above from Cloud Team member perspective I'd like to see this done. I also know that JEB was suggesting something similar some time ago. I don't think that any of the Cloud Team members or DDs would be against this solution, but if they would is it should be know, that's why cross post to debian-cloud (sorry for this) so people can vice their opinion. At this point in time I'm not capable of helping with backends but I could help with integrating db.d.o with our AWS account (I'm one of the admins) however we'll choose to do it. From experience I also know that not too many non DD or DMs are having access to those (AWS,GCP) accounts. So focusing on those 2 groups should be sufficient for start. -- |_|0|_| | |_|_|0| "Panta rei" | |0|0|0| kuLa | gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: PGP signature
Re: openssl/libssl1 in Debian now blocks offlineimap?
Quoting Hanno Rince' Wagner (2017-08-20 22:01:51) > On Fri, 18 Aug 2017, Tollef Fog Heen wrote: > > > I think you're wrong on this point, having Debian make this change makes > > it a lot easier for me to go to company management and explain that TLS > > v1.2 is the only way forward and that we need to spend engineering > > resources to make sure any users on platforms where support for that is > > lacking get a proper notification and a chance to move to something > > newer. «We need to do this because this change is coming, whether we > > want it or not.» > > If you need more "firepower" for management: The BSI (german > governmental organisation for security in information technology) has > guidelines regarding cryptography, see > > https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf > > They say in their technical guidelines that TLS 1.1 is not recommended > anymore and TLS 1.0 is not recommended at all. > SSLv2 and SSLv3 are not recommended. > > So, if managers want to have somewhere "officially" written that > TLS1.0 and 1.1 shouldn't be used anymore, this is a guideline I can > recommend. > > And IMHO we as debian should support all people going for stronger > encryption by enabling it as good as possible and make it default. If > someone wants or needs to use older ciphers, he should be able to, but > it shouldn't be default... I believe noone in this thread disagree with _recommending_ only TLS 1.2 and that no services _should_ use anything else. Question is if Debian _force_ only TLS 1.2 so that no services _can_ use anything else. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#845789: ITP: spymemcached -- simple, asynchronous, single-threaded memcached client written in java
Package: wnpp Followup-For: Bug #845789 Owner: Christopher Hoskin Work in progress here: https://anonscm.debian.org/cgit/pkg-java/spymemcached.git/ Christopher Hoskin
Re: OpenSSL disables TLS 1.0 and 1.1
Hi, On Sun Aug 20, 2017 at 21:54:12 +0200, Michael Meskes wrote: > >> It'd be nice if, after all this discussion, you stated clearly whether > >> you plan to change something or not. > > > > Isn't that what I just did? > > No, not exactly. You stated what you want to do in *Buster*, but not > whether it's supposed to stay broken all the way until then. I guess > this email of yours does make it clear, though. > > I guess we should then move the discussion from "should libssl support > TLS 1.0/1.1" to "how do we get a system again that works with the > not-so-up-to-date rest of the world". > > At least I think our social contract demands we offer a *working*" ssl > setup: > ... > We will be guided by the needs of our users and the free software > community. We will place their interests first in our priorities. We > will support the needs of our users for operation in many different > kinds of computing environments. > ... +1 -- Martin Zobel-Helas Debian System Administrator Debian & GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B
Bug#872763: node-clean-yaml-object
Package: wnpp Severity: wishlist Owner: ro...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-clean-yaml-object Version : 0.1.0 Upstream Author : James Talmage (github.com/jamestalmage) * URL : https://github.com/tapjs/clean-yaml-object#readme * License : Expat Programming Lang: JavaScript Description : Safe clean of an object prior to serialization This module clean up (fille with zero) an object before sending to serialisation, thus avoiding to serialize private data. This module supports generalisation by allowing ones to specify filter function, that support whitelisting. . Clearing data before serialization is critical from a security point of view in order to avoid leaking information. . Node.js is an event-based server-side JavaScript engine.
salsa.debian.net
I received some key SSH import notices from salsa.debian.net, but I didn't request anything. Is this harmless, or is something fishy going on?
Re: salsa.debian.net
Hi Florian, On Mon, Aug 21, 2017 at 06:50:06AM +0200, Florian Weimer wrote: > I received some key SSH import notices from salsa.debian.net, but I > didn't request anything. > > Is this harmless, or is something fishy going on? It looks this is the new collaboration server in replacement to alioth: https://wiki.debian.org/Salsa . I don't think there was yet an announcement yet, so maybe the SSH key import mails were sent out not intentionally yet. HTH, Regards, Salvatore
Bug#872773: ITP: firefox-passff -- pass manager extension for Firefox
Package: wnpp Severity: wishlist Owner: =?utf-8?b?WWFvIFdlaSAo6a2P6YqY5bu3KQ==?= -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: passff Version : 1.0.0 Upstream Author : Nathan Wallace * URL : http://github.com/passff/passff * License : GPL-2.0 Programming Lang: JavaScript Description : pass manager extension for Firefox and Chromium This is a browser extension to pass password manager. The extension itself uses WebExtension, hence it is cross platform between chromium and firefox. This package should be placed under collab-maint for comaintaining. -BEGIN PGP SIGNATURE- iQJCBAEBCAAsFiEE/tVDSEUoffJikxSJz7v84LdPGxQFAlmac+wOHG13ZWlAbHhk ZS5vcmcACgkQz7v84LdPGxQC9Q//YUGwZwHgJPhaI351eJxUNHWjKrWKieXF/rOy gyYnTe7QcqXUe0c5uq/1KKiiL/P+VubFmyshj7tTb44OIYKy6TrL1GMZOM33VV2W RD4u2wHrsvPeN+LWkVox/qdDkXR/fZO22rMdV5B/mjRJbtNmLhW83peBKIapfcrh S3+N+eAkwrC98xm/hxpl2qcFn43wuvkwAUdvYsnm+kPAG3KQEVAw53cF7CEBREQ4 PAbLQnIeONT6f9Z4nyz6A+loINFmVVN5Z+g2YTXHU8ieotGkwvKTxSRmY8a7gGZr vcW62J0Dtn2McUQx4W5d9AKua5owDDrJ7q6GMJVo6ZvZ/qYQtG2Fgh8goW6gxwbK fHH0WuueAAKHZ72cSIRHJg3TpUaDFQXLycs80Extf5q9z4SVrzDXrQioDf1Ymp25 j5aOQtpWZ+u3MsjNGp6cUYFH5mIGGepq1XP9f7ahyTauJ990OBKjB+ydH8+uH3DZ Sa4OIdltybPeI355WINBa4XKl1daRujGptYI/feDa036e9DUsy2R9/3Q3bMWybL9 /LBvdlmDG4rOShZ4ixSfyrEtSMt6vtVu+Q3UjhfB8XvbqtSsOK3FgTd4f7V6UEij kS9LppRbnqwdbaMkxrckJulk2Akgje0KS8SbqGrZZWVhUXdablruEXqkt+5UoyIY MDg9++Q= =1Zhz -END PGP SIGNATURE-
Re: salsa.debian.net
On 14771 March 1977, Florian Weimer wrote: > I received some key SSH import notices from salsa.debian.net, but I > didn't request anything. > Is this harmless, or is something fishy going on? Harmless, sorry. Salvatore guessed right, and the mails had been a mistake at that point. -- bye, Joerg
