Bug#740806: ITP: python-oslo.vmware -- VMware library for OpenStack projects
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-oslo.vmware Version : 0.2 Upstream Author : Vipin Balachandran * URL : https://github.com/openstack/oslo.vmware * License : Apache-2.0 Programming Lang: Python Description : VMware library for OpenStack projects This package is part of the Oslo project, which aims at providing unified Python libraries across all of OpenStack. It provides a VMware library for OpenStack projects. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305074903.14452.59740.report...@buzig.gplhost.com
Bug#740805: ITP: python-croniter -- provides iteration for datetime object with cron like format
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-croniter Version : 0.3.4 Upstream Author : Matsumoto Taichi * URL : https://github.com/kiorky/croniter * License : Expat Programming Lang: Python Description : provides iteration for datetime object with cron like format Croniter is a python module to provide iteration for datetime object. Given a cron tab text entry as input, it Croniter will output all the dates matching the definition. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305072518.10944.98925.report...@buzig.gplhost.com
Re: RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)
On Tue, Mar 4, 2014, at 21:33, Gunnar Wolf wrote: > Ondřej Surý dijo [Tue, Mar 04, 2014 at 08:10:47PM +0100]: > > On Mon, Mar 3, 2014, at 19:13, Gunnar Wolf wrote: > > > As keyring maintainers, we no longer consider 1024D keys to be > > > trustable. We are not yet mass-removing them, because we don't want to > > > hamper the project's work, but we definitively will start being more > > > aggressively deprecating their use. 1024D keys should be seen as > > > brute-force vulnerable nowadays. Please do migrate away from them into > > > stronger keys (4096R recommended) as soon as possible. > > > > I am not sure what's the timeframe for GnuPG 2.1.0[1] release, but would > > it be possible to skip the RSA and go directly for ECDSA, before we > > start deprecating DSA? Or at least have an option to do so? (Well, > > unless GnuPG 2.1 release is too much far in the future.) > > Umh, I feel I have to answer this message, but I clearly don't have > enough information to do so in an authoritative way¹. AIUI, ECDSA has > not been shown to be *stronger* than RSA — RSA works based on modulus > operations, ECDSA on curve crypto. ECDSA keys can be smaller and > achieve (again, AIUI) the same level of security. But nothing so far > shows that RSA will be broken before or after ECDSA. > > Barring somebody pointing me to the right place to read, my take would > be that we should accept both RSA and ECDSA keys Yes. I didn't suggest that we drop RSA. > (of what minimum size/strength?). These might provide a guidance (even for RSA key lengths). http://www.keylength.com/en/compare/#Biblio4 http://csrc.nist.gov/groups/ST/toolkit/key_management.html and http://csrc.nist.gov/publications/nistpubs/800-78-3/sp800-78-3.pdf NIST seems to recommend at least 2048 bits for RSA and Curve P-256 for ECDSA O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1394004577.30973.90743553.7342f...@webmail.messagingengine.com
Re: RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)
On Wed, Mar 5, 2014, at 7:58, Bastian Blank wrote: > On Wed, Mar 05, 2014 at 06:54:53AM +, Ondřej Surý wrote: > > > Also ECDSA shares with DSA the serious disadvantage over RSA that making > > > signatures on a system with a broken RNG can reveal the key. > > Care to share a source? I thought that RSA would be vulnerable to poor RNG > > as well. > > The algorithm. DSA and ECDSA need randomness in the signature process, > see Wikipedia. > > RSA only takes randomness during key generation. I see, for the reference RFC6979 provides more information (and remedy for the problem). Thanks for the hint, I have googled for "ECDSA broken RNG" that didn't reveal the correct source. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1394004176.29929.90741897.31dee...@webmail.messagingengine.com
Re: RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)
On Wed, Mar 05, 2014 at 06:54:53AM +, Ondřej Surý wrote: > > Also ECDSA shares with DSA the serious disadvantage over RSA that making > > signatures on a system with a broken RNG can reveal the key. > Care to share a source? I thought that RSA would be vulnerable to poor RNG as > well. The algorithm. DSA and ECDSA need randomness in the signature process, see Wikipedia. RSA only takes randomness during key generation. Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, "Dagger of the Mind", stardate 2715.1 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305065853.ga31...@mail.waldi.eu.org
Re: RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)
On 5. 3. 2014, at 5:54, peter green wrote: >> >> I am not sure what's the timeframe for GnuPG 2.1.0[1] release, but would >> it be possible to skip the RSA and go directly for ECDSA, before we >> start deprecating DSA? Or at least have an option to do so? (Well, >> unless GnuPG 2.1 release is too much far in the future.) > IMO we need to phase out 1024 bit RSA/DSA keys as soon as reasonablly > practical. Even if gnupg 2.1 was released tomorrow we would still have the > problem of Debian stable releases and other distros carrying older versions. You have convinced me :). Even though the attack surface is lowered by the fact that you would (probably) notice the malicious upload with your compromised key. But the reputation harm would still be there. > Also ECDSA shares with DSA the serious disadvantage over RSA that making > signatures on a system with a broken RNG can reveal the key. Care to share a source? I thought that RSA would be vulnerable to poor RNG as well. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Re: Bits from the autopkgtest maintainer
Antonio Terceiro wrote: > On Mon, Mar 03, 2014 at 11:22:23PM +0100, Jakub Wilk wrote: >> * Martin Pitt , 2014-02-27, 17:38: >> >Tests can now depend on "@builddeps@" which expands to the source >> >package's build dependencies. This is useful if you have many >> >build dependencies which are only necessary for running the test >> >suite and you don't want to replicate them in the test Depends:. >> >> I advise to never use @builddeps@. It's a great way to shoot >> yourself in the foot. :\ > > would you ellaborate? I would consider it to be a poor test of the built package if packages that were not in Recommends, Suggests or packages specifically needed as a test runner (e.g. python-nose) were being installed. Installing packages other than those ones means that whether the Depends/Recommends/Suggests are complete is not being tested [1]. This is a class of bug that keeps coming up and one of the reasons why autopkgtest tests are so attractive. There is of course another class of tests where correct operation is ensured while other non-required packages are installed (e.g. an alternative implementation etc) but that still isn't build-deps. (I don't know if that's what Jakub had in mind, but that's my 2¢) cheers Stuart [1] Where possible, separate tests for Depends, Depends+Recommends, Depends+Recommends+Suggests would seem even better to test the graceful failure (or otherwise) in the absence of these related packages. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lf6ge0$v4h$1...@ger.gmane.org
RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)
I am not sure what's the timeframe for GnuPG 2.1.0[1] release, but would it be possible to skip the RSA and go directly for ECDSA, before we start deprecating DSA? Or at least have an option to do so? (Well, unless GnuPG 2.1 release is too much far in the future.) IMO we need to phase out 1024 bit RSA/DSA keys as soon as reasonablly practical. Even if gnupg 2.1 was released tomorrow we would still have the problem of Debian stable releases and other distros carrying older versions. Also ECDSA shares with DSA the serious disadvantage over RSA that making signatures on a system with a broken RNG can reveal the key. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5316bc2b.7040...@p10link.net
Bug#740800: ITP: python-crontab -- Python module for reading and writing crontab files
Package: wnpp Severity: wishlist Owner: Jordan Metzmeier * Package name: python-crontab Version : 1.7.2 Upstream Author : Martin Owens * URL : https://launchpad.net/python-crontab * License : GPL-3 Programming Lang: Python Description : Python module for reading and writing crontab files python-crontab is a Python module for reading and writing crontab files and accessing the system cron automatically and simply using a direct API. . Features include: . - Displaying and modifying system and user crontab files - Adding comments to be displayed with jobs - Validating jobs - Searching for jobs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305045349.19837.16139.reportbug@tesla.local
Bug#740799: ITP: libapp-ddflare-perl -- Provides ddflare, a command line Dynamic DNS utility that updates with the latest IP every 5 minutes
Package: wnpp Severity: wishlist Owner: Peter Roberts * Package name: libapp-ddflare-perl Version : 0.05 Upstream Author : Peter Roberts * URL : http://metacpan.org/release/App-DDFlare * License : MIT Programming Lang: Perl Description : Provides ddflare, a CloudFlare command line Dynamic DNS utility Provides a command line utility, ddflare, which can be used to keep CloudFlare DNS records up to date automatically. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305044727.2395.34343.report...@pkg-deb.lan
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
On Wed, 2014-03-05 at 10:47 +0800, Paul Wise wrote: > On Wed, Mar 5, 2014 at 1:55 AM, Xavier Roche wrote: > > > I have a rather silly question: would a mail (signed with this key) > > request to the DDs who already signed the initial key (and checked the > > identity) to sign the replacement key considered unreasonable ? > > Considering that the initial keys are now considered weak, I expect > that it would be reasonable for people to not trust a key transition > statement where the only available trust anchor is the old weak key. That is however no reason not to do it - you're still better off than you were before (equally weak, but with the potential to improve). Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
On Wed, Mar 5, 2014 at 1:55 AM, Xavier Roche wrote: > I have a rather silly question: would a mail (signed with this key) > request to the DDs who already signed the initial key (and checked the > identity) to sign the replacement key considered unreasonable ? Considering that the initial keys are now considered weak, I expect that it would be reasonable for people to not trust a key transition statement where the only available trust anchor is the old weak key. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6Fr3xLJyDynSDY1kV5g-=yRsu_J8Jg_Bpy4PTuq=f4...@mail.gmail.com
Bug#740793: RFA: x-tile
Package: wnpp Severity: normal I don't use x-tile currently, and neither have the time nor the motivation to maintain it, so I'd prefer some other to do it properly. Said that, it should not be difficult at all to maintain, as upstream has been inactive for years. I'm open to sponsorship, so you don't need to be an uploading developer right now, but you should be in your way to become one. -- Ricardo Mones http://people.debian.org/~mones «Did you hear that two rabbits escaped from the zoo and so far they have only recaptured 116 of them?» signature.asc Description: Digital signature
Bug#740791: ITP: golang-go.crypto-dev -- Supplementary Go cryptography libraries.
Package: wnpp Severity: wishlist Owner: Tonnerre LOMBARD * Package name: golang-go.crypto-dev Version : 0.0~hg190 Upstream Author : The Go Authors * URL : http://code.google.com/p/go.crypto/ * License : BSD-3-Clause Programming Lang: Go Description : Supplementary Go cryptography libraries. This repository holds supplementary Go cryptography libraries which are not part of the main Go distribution. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140304232958.4627.45331.report...@phileas.roam.internetputzen.com
Re: RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)
On Tue, Mar 04, 2014 at 08:10:47PM +0100, Ondrej Surý wrote: > On Mon, Mar 3, 2014, at 19:13, Gunnar Wolf wrote: > > As keyring maintainers, we no longer consider 1024D keys to be > > trustable. We are not yet mass-removing them, because we don't want to > > hamper the project's work, but we definitively will start being more > > aggressively deprecating their use. 1024D keys should be seen as > > brute-force vulnerable nowadays. Please do migrate away from them into > > stronger keys (4096R recommended) as soon as possible. > > I am not sure what's the timeframe for GnuPG 2.1.0[1] release, but would > it be possible to skip the RSA and go directly for ECDSA, before we > start deprecating DSA? Or at least have an option to do so? (Well, > unless GnuPG 2.1 release is too much far in the future.) Do you have any idea which curves and/or signature algorithms are supported? I think I would like to see EdDSA in that case. I would also like to see that they get started on PGP v5. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140304225640.ga11...@roeckx.be
Bug#740788: ITP: sems -- SIP Express Media Server, very fast and flexible SIP media server
Package: wnpp Severity: wishlist Owner: Victor Seva -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: sems Version : 1.5.0 Upstream Author : Raphael Coeffic , Stefan Sayer , Juha Heinanen, Maxim Sobolev, Andreas Granig * URL : http://iptel.org/sems * License : GPLv2+ & openssl linking exception Programming Lang: C++, Python Description : SIP Express Media Server, very fast and flexible SIP media server SEMS, the SIP Express Media Server, is a free, high performance, extensible media server for SIP (RFC3261) based VoIP services. It features voicemail, conferencing, announcements, pre-call announcements, prepaid service, calling card service etc. This package will be maintained under the pkg-voip team umbrella. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlMWV+UACgkQS/DSSd0S8lO73ACeLhz0J7aW8yhwReYPPo62kz1H ce4An3U582HveEx6+yLRRp+pOHQ8QjPr =6XRU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140304224720.26075.30353.reportbug@acer
Bug#740783: ITP: timeside -- open web audio processing framework
Package: wnpp Severity: wishlist Owner: Paul Brossier * Package name: timeside Version : 0.5.4 Upstream Author : Guillaume Pellerin * URL : https://github.com/yomguy/TimeSide * License : GPL-2+ Programming Lang: Python Description : open web audio processing framework TimeSide is a set of Python components enabling easy audio processing, transcoding, imaging and streaming. Its simple architecture and high-level API have been design to process serial pipelines. . It includes a powerful HTML5 interactive player which can be embedded in any web application to provide fancy waveforms, various analyzer results, synced time metadata display during playback (time-marking) and remote indexing. . The engine (server side) is fully written in Python, the player (client side) in HTML, CSS and JavaScript. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140304214841.12560.82210.reportbug@groseille.localdomain
Bug#740779: ITP: ruby-coveralls -- Ruby implementation of the Coveralls API
Package: wnpp Severity: wishlist Owner: Miguel Landaeta * Package name: ruby-coveralls Version : 0.7.0 Upstream Author : Nick Merwin , Wil Gieseler * URL : https://github.com/lemurheavy/coveralls-ruby * License : MIT/X Programming Lang: Ruby Description : Ruby implementation of the Coveralls API Coveralls is a web service to help you track your code coverage over time, and ensure that all your new code is fully covered. . Coveralls automatically collects your code coverage data, uploads it to their servers and gives you a nice interface to dig into it. . Any type of Ruby project or test framework supported by SimpleCov is supported by the Coveralls gem. This includes all your favorites, like RSpec, Cucumber, and Test::Unit. . This package provides a Ruby gem to interact with Coveralls API. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9 "Faith means not wanting to know what is true." -- Nietzsche signature.asc Description: Digital signature
Re: RSA vs ECDSA
Moin! Gunnar Wolf writes: > Ondřej Surý dijo [Tue, Mar 04, 2014 at 08:10:47PM +0100]: >> On Mon, Mar 3, 2014, at 19:13, Gunnar Wolf wrote: >> > As keyring maintainers, we no longer consider 1024D keys to be >> > trustable. We are not yet mass-removing them, because we don't want to >> > hamper the project's work, but we definitively will start being more >> > aggressively deprecating their use. 1024D keys should be seen as >> > brute-force vulnerable nowadays. Please do migrate away from them into >> > stronger keys (4096R recommended) as soon as possible. >> >> I am not sure what's the timeframe for GnuPG 2.1.0[1] release, but would >> it be possible to skip the RSA and go directly for ECDSA, before we >> start deprecating DSA? Or at least have an option to do so? (Well, >> unless GnuPG 2.1 release is too much far in the future.) Note that this also requires a backported gnupg 2.1 on every debian service processing signatures (and everyone else who should interpret these) -- I'd asume this is only really feasible post jessie (assuming jessie gets a new enough gnupg). Christoph pgpU7DkXUuibm.pgp Description: PGP signature
Bug#740768: ITP: ruby-sawyer -- HTTP/REST API client Ruby library
Package: wnpp Severity: wishlist Owner: Miguel Landaeta * Package name: ruby-sawyer Version : 0.5.3 Upstream Author : Rick Olson * URL : https://github.com/lostisland/sawyer * License : MIT/X Programming Lang: Ruby Description : HTTP/REST API client library All upstream documentation describes is: Experimental HTTP User Agent implemented on top of ruby-faraday. So, I'll have to review this with upstream to improve it. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9 "Faith means not wanting to know what is true." -- Nietzsche signature.asc Description: Digital signature
Re: RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)
Ondřej Surý dijo [Tue, Mar 04, 2014 at 08:10:47PM +0100]: > On Mon, Mar 3, 2014, at 19:13, Gunnar Wolf wrote: > > As keyring maintainers, we no longer consider 1024D keys to be > > trustable. We are not yet mass-removing them, because we don't want to > > hamper the project's work, but we definitively will start being more > > aggressively deprecating their use. 1024D keys should be seen as > > brute-force vulnerable nowadays. Please do migrate away from them into > > stronger keys (4096R recommended) as soon as possible. > > I am not sure what's the timeframe for GnuPG 2.1.0[1] release, but would > it be possible to skip the RSA and go directly for ECDSA, before we > start deprecating DSA? Or at least have an option to do so? (Well, > unless GnuPG 2.1 release is too much far in the future.) Umh, I feel I have to answer this message, but I clearly don't have enough information to do so in an authoritative way¹. AIUI, ECDSA has not been shown to be *stronger* than RSA — RSA works based on modulus operations, ECDSA on curve crypto. ECDSA keys can be smaller and achieve (again, AIUI) the same level of security. But nothing so far shows that RSA will be broken before or after ECDSA. Barring somebody pointing me to the right place to read, my take would be that we should accept both RSA and ECDSA keys (of what minimum size/strength?). It should not be in any way different than what we currently do. But anybody looking at a mistake in my text, *please* correct me! -- ¹ Outside, that is, from the authority vested by delegating me part of keyring-maint ;-) signature.asc Description: Digital signature
Bug#740766: ITP: ruby-multimap -- Ruby multimap implementation
Package: wnpp Severity: wishlist Owner: Jonas Genannt -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: ruby-multimap Version : 1.1.2 Upstream Author : Joshua Peek * URL : https://github.com/josh/multimap * License : MIT Programming Lang: Ruby Description : Ruby multimap implementation Multimap includes a Ruby multimap implementation For Gitlab, maintained by Ruby PKG Group gem does not include spec files: https://github.com/josh/multimap/pull/4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJTFjW6AAoJEPBM7/YBbP/Q474P/0kvKYr3q5Ge3yzQqy2EQl9i XzdcKbonJEa9zd//kDl8NPIl2iZ/4K55Gvm1jlW+7KJ2OdQ/rEDdWWt7uHTVaEyg h/5pUdjaZ28nfYj1iTfJtQaHI48OZMWNejGGTzQ3XWR4jYKWFVXydmQJ/kKl+P7S 74czewHhw6EpngK5SnMl2mRtAN7JkHwIoNUy4ZSNnEwOZ8j4NFGBijs20u+xsRCC DZj3IhtfdJ2v3zYeedQgojrYRvHvM3ef1bhJAsklxFIilRqYi1c1Hqe9X5K99gKL JZkuu9M5mLwwdxcoiyVP7ug5vleq3maDb9wffZ1OggmfWkdsSXlUQE2ouIAYwJyz emvMtRab5cxJ+RGdktMhqiwylKCrWB+GLTzHrG8K53I+IygTuJMsQIQM/eSuDzvC ANHxNag/WXkDpd+2A8mw9rdLnm7nA8DXQvmly95nwdWEZI6jZ8Uf6sivA9XSSNhk +TZYtrzGedpJBZ6GIYr0pqmF1OawO3d465h2ykzLc/Osv5ii/pPaAWQ08/sPOamj ZV8Q200k+NL0TxvDDYlKyRSXhGAdQI90ScqCXGzcHM6kkTamYkaLgdhVOtJ9wt+U uqbP/VOzyLboTq8g1Sr35l6c7vpXyxvE+KlXNx9/wv1g8cG2qx8wjMK4qYb99XEj DdMFmAIaEiWtZcDXDAwI =HJb/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140304202114.19883.19218.report...@swetlana.brachium-system.net
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
Xavier Roche dijo [Tue, Mar 04, 2014 at 06:55:08PM +0100]: > I have a rather silly question: would a mail (signed with this key) > request to the DDs who already signed the initial key (and checked the > identity) to sign the replacement key considered unreasonable ? > > And would it be considered reasonable if the first key was strong ? > > This is not something possible as far as I can see, but is there any > security rationale behind this ? It all depends on the policies of each individual that signed your original, weak key. I personally do not sign keys based on transition statements. Some people will. Anyway, we as keyring maintainers cannot know how far did you go to check the identities. signature.asc Description: Digital signature
Bug#740761: ITP: ruby-axiom-types -- Ruby module for abstract types for logic programming
Package: wnpp Severity: wishlist Owner: Jonas Genannt -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: ruby-axiom-types Version : 0.1.0 Upstream Author : Dan Kubb * URL : https://github.com/dkubb/axiom-types * License : MIT Programming Lang: Ruby Description : Ruby module for abstract types for logic programming Define types with optional constraints for use within axiom and other libraries. Abstract types for logic programming For gitlab, maintained by Ruby PKG Group -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJTFihuAAoJEPBM7/YBbP/QsEEP/1EHGyI1yiGBJc0VOPi7V0Xl xDg0rasgKBVH0X+rks6Werpk9+rT4cszNjNAm130smgRnHWGWJa2ft7IUqcAnps7 1rSYRdaRg23zTY6bfjh7BV9PkTr1kqkGUZF7Vsy8I/t4xyu5d8Cov5IhglZ9sggj hytsyEnCQH4uTpl86uD4O3qOKESp616lGoYYuZKzCfSk0YrSeQ+5Mpwqq23soWs+ MUTTq2SEisIhJaqtraPgylPDLSHrUbYOZI0PYH75XKb2zvrhNRhMYBITWwE3sVl7 eg91hsnXES/l/0JyRKtZLrKoQhKYyOY7L8Twb5DOya0JjvieoxaCsuVCu8JIWz6I qFWv+Z0Fz4tnpAyAX/7Yqgt0eFAWUYwDTBUJ+8Kf4FQ4DdLjFha669eQFM7Q15Wt wclUSMxexGkVK8x9XOB+Zq7+fq9S3rMMMHWS/2EV84580GtO6aZ/PwUifPi7pmfN bAisf0PuwKGz1zccJqJvSrNd075cua2rUEW3s5Jq+8hcCmtCl2kPgjL5njpZ/ydG QF/vXY4oEimewmt/ibbObmocdB5zLXsR5yyybgrgIMDqAlvJg8lLUAh1UwfPUcJS 4EC0JhU3W5TCJBCVybMTB4QdQ+jh4SDvkGGiG2iZf90pcbMuMGwNVSeb28wtQEGR f5jIGm4gl7K0wLGlxpjP =1dDO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140304192431.11568.34182.report...@swetlana.brachium-system.net
RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)
On Mon, Mar 3, 2014, at 19:13, Gunnar Wolf wrote: > As keyring maintainers, we no longer consider 1024D keys to be > trustable. We are not yet mass-removing them, because we don't want to > hamper the project's work, but we definitively will start being more > aggressively deprecating their use. 1024D keys should be seen as > brute-force vulnerable nowadays. Please do migrate away from them into > stronger keys (4096R recommended) as soon as possible. I am not sure what's the timeframe for GnuPG 2.1.0[1] release, but would it be possible to skip the RSA and go directly for ECDSA, before we start deprecating DSA? Or at least have an option to do so? (Well, unless GnuPG 2.1 release is too much far in the future.) 1. http://lists.gnupg.org/pipermail/gnupg-devel/2011-February/025949.html O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1393960247.19940.90519781.6b051...@webmail.messagingengine.com
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
Le 03/03/2014 19:13, Gunnar Wolf a écrit : > If you have a key with not-so-many active DD signatures (with > not-so-many ≥ 2) waiting to get it more signed, stop waiting and > request the key replacement². I have a rather silly question: would a mail (signed with this key) request to the DDs who already signed the initial key (and checked the identity) to sign the replacement key considered unreasonable ? And would it be considered reasonable if the first key was strong ? This is not something possible as far as I can see, but is there any security rationale behind this ? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5316137c.1030...@httrack.com
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
Vincent Danjean dijo [Tue, Mar 04, 2014 at 05:16:43PM +0100]: > On 03/03/2014 19:13, Gunnar Wolf wrote: > > If you have a key with not-so-many active DD signatures (with > > not-so-many ≥ 2) waiting to get it more signed, stop waiting and > > request the key replacement². > > Is there a way to check this requirement? I've a 4096R key since > 2010 that I made signed by various people. How can I count how many > signatures have been done by people in the current Debian Keyring ? > Extra bonus if I can count signatures from the Debian keyring AND > that will be kept here (ie with key >= 4096R) > If a gpg expert can give a small script to make these checks, it > will be appreciated. Just adding to the already-replied answer (keycheck.sh): We check against the live keyring. This means, however, that if we have just updated the key for DD X, and you have X's signature with the old key, our scripts won't recognize it. Of course, it also means that if Y signed you with a new key, and we have not yet processed Y's request, his new key will not show up in our working tree :-| ...Which sucks, yes. But then again, we might reject your request as it does not have enough signatures, then you tell us, "oh, but it does!". We re-evaluate, and (hopefully!) everybody will be happy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140304171745.gi73...@gwolf.org
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
Jonathan McDowell dijo [Tue, Mar 04, 2014 at 05:38:11AM +]: > > Surely this is well within keyring-maint purview and a GR is thus > > unnessecary? Running the plan by debian-project seems a reasonable > > level of consultation. > > We didn't need one for removing PGPv3 keys so I don't see why we'd need > one for 1024D v4 keys. I was thinking that we might need it just because of the amount of keys. We will end up locking out *many* DDs. > I have already suggested a timescale to -project but haven't seen any > comments on it other than "you should script this" and "should we relax > the requirement for 2 signatures". Right. And that basically gives us green light - But, yes, some will argue it's only involving people actively following said list. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140304171151.gh73...@gwolf.org
Re: Adiscon LogAnalyzer? rsyslog + mongodb?
* Daniel Pocock [2014-03-04 15:49:25 +0100]: > > I didn't see any existing package of LogAnalyzer from Adiscon, the > people who make rsyslog - is there any specific reason for not packaging > it or it is just not something anybody needed yet? It is GPL: > > http://loganalyzer.adiscon.com/ > > http://download.adiscon.com/loganalyzer/loganalyzer-3.6.5.tar.gz > > The rsyslog mongodb output module and the PHP mongodb modules are now in > wheezy-backports. This would appear to be sufficient to do something like: > > rsyslog => mongodb => loganalyzer > > Has anybody else tried that or does anybody have any comments on it (or > recommended alternatives)? > > http://loganalyzer.adiscon.com/articles/using-mongodb-with-rsyslog-and-loganalyzer/ Hi, At work, I have been investigating the ElasticSearch + Logstash[1] + Kibana[2] combo, which has been pretty solid in my tests so far (feeding it 10GB or so of firewall logs a day, yes, that thing is noisy). There is no Debian packaging of that stack yet (the RFP of logstash is at [3]), and I haven't investigated the upstream-provided repositories either (AIUI, they appeared after my tests, so I ran the stuff from the "flatjar" bundle, ick). [1] http://www.elasticsearch.org/overview/kibana/ [2] http://www.elasticsearch.org/overview/logstash/ [3] https://bugs.debian.org/664841 Cheers and HTH, -- Nicolas Dandrimont "Problem solving under linux has never been the circus that it is under AIX." (By Pete Ehlke in comp.unix.aix) signature.asc Description: Digital signature
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
* Vincent Danjean [2014-03-04 17:16:43 +0100]: > On 03/03/2014 19:13, Gunnar Wolf wrote: > > If you have a key with not-so-many active DD signatures (with not-so-many ≥ > > 2) waiting to get it more signed, stop waiting and request the key > > replacement². > > Is there a way to check this requirement? I've a 4096R key since > 2010 that I made signed by various people. How can I count how many > signatures have been done by people in the current Debian Keyring ? > Extra bonus if I can count signatures from the Debian keyring AND > that will be kept here (ie with key >= 4096R) > If a gpg expert can give a small script to make these checks, it > will be appreciated. You can use keycheck.sh, the script AMs used to use in the NM process. I'm not sure if it's packaged, but it's at http://anonscm.debian.org/viewvc/nm/trunk/nm-templates/keycheck.sh?revision=1251&view=markup Cheers, -- Nicolas Dandrimont "Never make any mistaeks." (Anonymous, in a mail discussion about to a kernel bug report.) signature.asc Description: Digital signature
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/03/2014 19:13, Gunnar Wolf wrote: > If you have a key with not-so-many active DD signatures (with not-so-many ≥ > 2) waiting to get it more signed, stop waiting and request the key > replacement². Is there a way to check this requirement? I've a 4096R key since 2010 that I made signed by various people. How can I count how many signatures have been done by people in the current Debian Keyring ? Extra bonus if I can count signatures from the Debian keyring AND that will be kept here (ie with key >= 4096R) If a gpg expert can give a small script to make these checks, it will be appreciated. Regards, Vincent - -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIVAwUBUxX8Z9T1zgD6DpudAQjZoBAAjmRRJZvCcxjMXgmjp1XN6Q7Rg+infCel hyU6vO1LXS2WJyk5h2Jxt+6chTLvoBOHDDcJ3RJRbSKFEyx3VnIeR8VuIFkdeLa3 B/8UqvBfO70OE4jVQbHgkViJeSHEK7/5Hy/dbzZlq6x6NSyxk6dO8fs4bsvPMHE/ bbRyr0/VRJNtURLg8OzUOiXEPtxtRGOnLpBZZ/lLT7Ulz6TtpminGsO+reH36oB0 ncq2VcTxSd86YJfBZbuzSz3X1lMHMAZfYArzRUxq2ICREIirKZxbw57hHMBuP77j kb88Lb5QZKWQcZk6jdbXepf4v276VdIUylCZ9N24wIipNpBSMrQ9BlESQNnYbqKY bQFtLEFS0Tq5ScuX6zX9tvogrfZwkSHGPAcpspaA5wQvkvj1hwGuy477Ut1Whe6q 7ioEfWzGyR7rdUcpQ2ChR5tgqhfA462uzUiwXa3OGEvzT+yEN0wqOHtg2F7zoMve rsHUVCslwg1u+0fcwbyEpjt7//TwtVmhYDl3EkyvAu43SS17iV6BmcVBnPEobAFO GqqBuYy6zP20hyfM7/8Uq3oxcnDwR8PClXR3tfQ36HFIjhtgJuDS9WUuuZmk4/bT PgzvRgDAiUKYId9zYF3jusD30tQNT39BXfd+1i7l9I3t0j4fGcZy11tXNIKOkxGy whEknL4Z7lc= =FOsp -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5315fc6b.9030...@free.fr
Adiscon LogAnalyzer? rsyslog + mongodb?
I didn't see any existing package of LogAnalyzer from Adiscon, the people who make rsyslog - is there any specific reason for not packaging it or it is just not something anybody needed yet? It is GPL: http://loganalyzer.adiscon.com/ http://download.adiscon.com/loganalyzer/loganalyzer-3.6.5.tar.gz The rsyslog mongodb output module and the PHP mongodb modules are now in wheezy-backports. This would appear to be sufficient to do something like: rsyslog => mongodb => loganalyzer Has anybody else tried that or does anybody have any comments on it (or recommended alternatives)? http://loganalyzer.adiscon.com/articles/using-mongodb-with-rsyslog-and-loganalyzer/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5315e7f5.5050...@pocock.pro
Bug#740736: ITP: ruby-octokit -- Ruby toolkit for the GitHub API
Package: wnpp Severity: wishlist Owner: Miguel Landaeta * Package name: ruby-octokit Version : 2.7.0 Upstream Author : Wynn Netherland , Erik Michaels-Ober , Clint Shryock * URL : http://octokit.github.io/octokit.rb/ * License : MIT/X Programming Lang: Ruby Description : Ruby toolkit for the GitHub API ruby-octokit.rb wraps the GitHub API in a flat API client that follows Ruby conventions and requires little knowledge of REST. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9 "Faith means not wanting to know what is true." -- Nietzsche signature.asc Description: Digital signature
Bug#740735: ITP: ruby-docker-api -- Ruby gem to interact with docker.io remote API
Package: wnpp Severity: wishlist Owner: Miguel Landaeta * Package name: ruby-docker-api Version : 1.8.2 Upstream Author : Swipely, Inc. * URL : https://github.com/swipely/docker-api * License : MIT/X Programming Lang: Ruby Description : Ruby gem to interact with docker.io remote API This Ruby gem provides an object-oriented interface to the Docker Remote API an a complete implementation. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9 "Faith means not wanting to know what is true." -- Nietzsche signature.asc Description: Digital signature
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
On 03/04/2014 09:24 PM, Jeremy T. Bouse wrote: > If any DDs are in, or will be, the Atlanta area and would like to get > together for a key signing I would be more than welcome to get together Most likely, I will attend the OpenStack summit in Atlanta [1] next May (from 12th to 16th). Even if I'm not there, there will most likely be a lot of DDs that will attend the event (from the top of my head: James Page & Robert Collins at least, probably even more). I'll be happy to sign your key if you show up to the event. Even if you're just at the door and don't want to pay the entry fee, that should be fine too, though since it's next to where you are, I would recommend you to attend the whole week: there's a lot to learn there. Cheers, Thomas Goirand (zigo) [1] http://www.openstack.org/summit/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5315e455.6060...@debian.org
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
I've actually been in the process of working to transition from my existing to 1024D key I created back in 2002 with my new 4096R key I created in 2011 that I use 3072R subkeys on a OpenPGP v2 smartcard. Unfortunately I haven't been able to get together with any other DDs to perform a key signing to get my new key sufficient enough to make the final transition. I notified everyone who had previously signed my current 1024D key but haven't been able to travel to make any major events and it's so far only signed by those that have attended local LUG keysignings in the past 2 years or individuals that have arranged to get together privately to do a key signing. If any DDs are in, or will be, the Atlanta area and would like to get together for a key signing I would be more than welcome to get together and make the transition as I currently don't even bother to keep my 1024D key with me for use anymore and only carry my smartcard with the 3072R subkeys while my 4096R primary key is still left secured in my fire safe at home on the encrypted USB drive it resides on. Current 1024D policy URL: http://undergrid.net/legal/gpg/policy/20091121 Transition statement: http://undergrid.net/legal/gpg/policy/20111223 New 4096D policy URL: http://undergrid.net/legal/gpg/policy/20111224 On 03.03.2014 14:37, Reuben Thomas wrote: On 3 March 2014 18:13, Gunnar Wolf wrote: As keyring maintainers, we no longer consider 1024D keys to be trustable. We are not yet mass-removing them, because we dont want to hamper the projects work, but we definitively will start being more aggressively deprecating their use. 1024D keys should be seen as brute-force vulnerable nowadays. Please do migrate away from them into stronger keys (4096R recommended) as soon as possible. Please could you change https://wiki.debian.org/DebianMaintainer [2] , which currently says a ">= 2048 bit" key is required (I assume this is still correct) but does not specifically recommend 4096? I recently became a DM, and created a 2048 bit key to do so, as that satisfied the advice given on that page, and also happened to be the default length offered by GPG on my system. Only after Id had it signed and uploaded it did I find advice that new keys should be 4096 bits. (Ive already reported this issue in a couple of different places; the page is not user-editable or Idve fixed it myself!) Links: -- [1] mailto:gw...@gwolf.org [2] https://wiki.debian.org/DebianMaintainer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a24f8679c031b0b76e8ed5cc0a9f4...@undergrid.net
Bug#740728: ITP: yorick-ynfft -- nonequispaced fast Fourier transform for Yorick
Package: wnpp Severity: wishlist Owner: Thibaut Paumard * Package name: yorick-ynfft Version : 0.0.1 Upstream Author : Éric Thiébaut * URL : http://cral.univ- lyon1.fr/labo/perso/eric.thiebaut/?Software/Yorick/YNFFT * License : CeCILL-C Programming Lang: C, Yorick Description : nonequispaced fast Fourier transform for Yorick YNFFT is a Yorick plug-in around the NFFT library for nonequispaced fast Fourier transform. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140304130712.11848.16245.report...@tantive-iv.obspm.fr
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
On Tue, Mar 04, 2014 at 06:27:38PM +1000, Alexander Zangerl wrote: > On Tue, 04 Mar 2014 04:46:17 +, Luca Filipozzi writes: > >I propose 2014-SEP-01. Gives people six months to get this done. Even *I* > >can > >get it done in that amount of time. I've already emailed my fellow Vancouver > >Debian Developers in the hopes of coordinating a revolution^Wkeysigning [1]. > > lucky you It was intended as a self-deprecating remark. None of my fellow Vancouver Debian Developers have replied! > - that schedule won't work for others like me here in AU; there's exactly one > other DD just under 100km away, the remaining few on the same continent are > all 1000+km distant, and i have zero budget and time for attending > conferences or other social gatherings. I appreciate that there are challenging circumstances. That said, I think we've had plenty of time to consider upgrading our keys (I'm at 1024D; I'm part of "we") already; I believe a firm date is needed to motivate people like me to Get It Done. The Keyring Maintainers have indicated that they will discuss individual circumstances if approached. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
On Tue, 04 Mar 2014 04:46:17 +, Luca Filipozzi writes: >I propose 2014-SEP-01. Gives people six months to get this done. Even *I* can >get it done in that amount of time. I've already emailed my fellow Vancouver >Debian Developers in the hopes of coordinating a revolution^Wkeysigning [1]. lucky you - that schedule won't work for others like me here in AU; there's exactly one other DD just under 100km away, the remaining few on the same continent are all 1000+km distant, and i have zero budget and time for attending conferences or other social gatherings. regards az -- Alexander Zangerl + GPG Key 0xB963BD5F (or 0x42BD645D) + http://snafu.priv.at/ This mind intentionally left blank. signature.asc Description: Digital Signature
