Bug#860116: [Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager
Josh Triplett: > [..] > > ...and looking at git from 20 minutes ago, it looks like you've switched > over to directory registries now. > Thanks for the tip, yes I figured this out by looking at both your dh-cargo code and also the Fedora cargo package. [1] The new version is uploaded to experimental, but there's some more things I'd like to tidy up before uploading it to unstable. - I get errors about missing "cargotest" and "hamcrest" when I try to `make test`, it looks like cargotest is actually in the rustc package: https://github.com/rust-lang/rust/tree/master/src/tools/cargotest Any suggestions on how to deal with this? I guess the obvious thing to do is to package a librust-cargotest-xxx-dev package but I wonder if there are better options. - cargo still embeds libgit2-sys source code, and I can see that in the deps-tarball-filter.txt Luca was explicitly leaving it in. Is that because they patch the source code? Can we just get rid of it, and link to libgit2 instead? X [1] https://src.fedoraproject.org/cgit/rpms/cargo.git/tree/cargo.spec -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#860771: ITP: node-diffie-hellman -- pure js diffie-hellman
On Thu, Apr 20, 2017 at 12:41 AM, Christian Seiler wrote: > On 04/19/2017 11:36 PM, Bastien ROUCARIES wrote: >> Package: wnpp >> Severity: wishlist >> Owner: ro...@debian.org >> X-Debbugs-CC: debian-de...@lists.debian.org >> >> * Package name: node-diffie-hellman >> Version : 5.0.2 >> Upstream Author : Calvin Metcalf >> * URL : https://github.com/crypto-browserify/diffie-hellman >> * License : Expat >> Programming Lang: JavaScript >> Description : pure js diffie-hellman key exchange >> >> Diffie–Hellman key exchange (D–H) is a specific method of securely >> exchanging cryptographic keys over a public channel. The >> Diffie–Hellman key exchange method allows two parties that have no >> prior knowledge of each other to jointly establish a shared secret key >> over an insecure channel. This key can then be used to encrypt >> subsequent communications using a symmetric key cipher. >> . >> Node.js is an event-based server-side JavaScript engine. > > Is this timing safe? From the github page it uses a pure-JS > BigNum implementation (bn.js) for the complicated stuff, but > the README of that code doesn't mention timing at all. And > from perusing the source code of bn.js, it doesn't appear to > be the case that their implementation of exponentiation in > a prime field is geared towards constant-time execution (when > the sizes are the same). > > If you look at e.g. OpenSSL's source code (bn_exp.c), there's > a specific function (bn_mod_exp_mont_consttime) in there that > takes great care of making sure that the operation runs in > constant time - down to how the memory layout is organized. I > wouldn't know how you'd even do that in an interpreted > language such as JavaScript, but even if that's possible, I'd > suspect that a lot of brain power would need to go into > designing that [1], while bn.js's implementation of the > Red.pow function seems rather straight-forward. (Which is > fine, bn.js appears to have the goal to be a generic bignum > library, and not targeted at crypto.) > > What I'm saying is: while not having tested that, I believe > that this implementation of DH is going to be susceptible to > timing attacks. (And if it isn't, the author should really > provide some rationale why not, with some test results. The > README is rather sparse, though.) Which would be fine if you > just wanted to use this library to generate the DH prime > itself (that is not timing critical), or just use it in an > academic context (to let people play around with DH), but > I'd not want to use this for real-world applications of the > actual key exchange protocol. I have planned to add a big fat warning about safety of browserify-crypto. I am myself unease to use it but it is needed for browserify. Do you prefer a README.debian per pure js crypto package ? I plan to patch browserify and add a flag in order to use the crypto API. > > Regards, > Christian > > [1] Especially if this is to be run in browsers, with > different JITs etc. Designing algorithms in pure JS > for these environments that are timing-safe looks rather > daunting to me.
Bug#860116: [Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager
On Thu, Apr 20, 2017 at 08:16:00AM +, Ximin Luo wrote: > Josh Triplett: > > [..] > > > > ...and looking at git from 20 minutes ago, it looks like you've switched > > over to directory registries now. > > > > Thanks for the tip, yes I figured this out by looking at both your dh-cargo > code and also the Fedora cargo package. [1] > > The new version is uploaded to experimental, but there's some more things I'd > like to tidy up before uploading it to unstable. > > - I get errors about missing "cargotest" and "hamcrest" when I try to `make > test`, it looks like cargotest is actually in the rustc package: > > https://github.com/rust-lang/rust/tree/master/src/tools/cargotest > > Any suggestions on how to deal with this? I guess the obvious thing to do is > to package a librust-cargotest-xxx-dev package but I wonder if there are > better options. > > - cargo still embeds libgit2-sys source code, and I can see that in the > deps-tarball-filter.txt Luca was explicitly leaving it in. Is that because > they patch the source code? > > Can we just get rid of it, and link to libgit2 instead? git2-rs doesn't modify libgit2, but it does use a snapshot from git, via a submodule. And unfortunately, while it supports building against a system version via pkg-config, it doesn't include any version number in its dependency. libgit2 itself doesn't have a stable ABI, so either an older *or* a newer version can potentially fail due to incompatibilities. (Also, like many libraries, libgit2 doesn't really update its SONAME and similar except when releasing, even though many people run git snapshots.) Fortunately, git2-rs uses ctest now to attempt to make sure its bindings match the actual signatures of the functions, so at least an attempt to build against an older (or sometimes newer) version of libgit2 will tend to produce compile errors (assuming you get all the environment variables set correctly to find it). However, I know of at least one case where git2-rs pulled in a new snapshot of libgit2 to obtain critical bugfixes rather than differences in ABI. In short, I think we *could* switch to pulling in the system version of libgit2, but we'd need to work very closely with the libgit2 maintainer, and sometimes package snapshots of libgit2 from git. We might also want to work with libgit2 and git2-rs upstreams to 1) get more regular updates to the version number that appears in the pkg-config file and 2) get libgit2-sys to declare a pkg-config dependency that matches its snapshot of libgit2. - Josh Triplett
Bug#860116: [Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager
On Thursday, April 20, 2017 8:16:00 AM UTC Ximin Luo wrote: > - cargo still embeds libgit2-sys source code, and I can see that in the > deps-tarball-filter.txt Luca was explicitly leaving it in. Is that because > they patch the source code? > > Can we just get rid of it, and link to libgit2 instead? It would be nice, but last time I tried upstream was tracking libgit2 from master: https://github.com/alexcrichton/git2-rs/pull/80 Things may have changed in the meanwhile, I did not re-assess since then. Ciao, Luca -- "If you build a wall, think of what you leave outside it" - Italo Calvino signature.asc Description: This is a digitally signed message part.
Bug#860771: ITP: node-diffie-hellman -- pure js diffie-hellman
On 04/20/2017 11:09 AM, Bastien ROUCARIES wrote: > I have planned to add a big fat warning about safety of > browserify-crypto. I am myself unease to use it but it is needed for > browserify. > > Do you prefer a README.debian per pure js crypto package ? Maybe also add something along the lines of | For security considerations of this package please consult | README.Debian. to the package's extended description? (Or is that against policy?) > I plan to patch browserify and add a flag in order to use the crypto API. Isn't browserify a JS minifier? Why would that need DH key exchange anyway? I'm a bit confused here... Regards, Christian
Bug#726668: dtmf2num
Hello Dominik If you're still missing the package, here it is (not completely ready, but working): http://sid.ethz.ch/debian/dtmf2num/ Yours,
Processed: highwayhash: block ITP 848885 by RFS 860804
Processing commands for cont...@bugs.debian.org: > block 848885 by 860804 Bug #848885 [wnpp ] ITP: highwayhash -- Fast strong hash functions: SipHash/HighwayHash 848885 was not blocked by any bugs. 848885 was blocking: 804612 Added blocking bug(s) of 848885: 860804 > stop Stopping processing here. Please contact me if you need assistance. -- 848885: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848885 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#858458: marked as done (ITP: lbry -- A fully decentralized network for distributing data)
Your message dated Thu, 20 Apr 2017 14:56:46 -0400 with message-id and subject line Fwd: ITP: lbry -- A fully decentralized network for distributing data has caused the Debian Bug report #858458, regarding ITP: lbry -- A fully decentralized network for distributing data to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 858458: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858458 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: wishlist * Package name: lbry Upstream Author : LBRY Inc * URL : https://github.com/lbryio/lbry * License : Expat Programming Lang: Python Description : LBRY is a blockchain/swarm-based content sharing and publishing platform that is decentralized and owned by its users. It is in the news for preserving the ADA-deficient lecture archive being taken down by UC Berkeley. --- End Message --- --- Begin Message --- I'm realizing that I will not be able to get to this. Releasing for someone else to implement. -- Forwarded message -- From: David Steele Date: Wed, Mar 22, 2017 at 11:01 AM Subject: ITP: lbry -- A fully decentralized network for distributing data To: Debian Bug Tracking System Package: wnpp Severity: wishlist * Package name: lbry Upstream Author : LBRY Inc * URL : https://github.com/lbryio/lbry * License : Expat Programming Lang: Python Description : LBRY is a blockchain/swarm-based content sharing and publishing platform that is decentralized and owned by its users. It is in the news for preserving the ADA-deficient lecture archive being taken down by UC Berkeley. -- AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE--- End Message ---
Bug#854508: No activity
control: owner -1 ro...@debian.org Hi, Without ctivity I take this bug report
Processed: No activity
Processing control commands: > owner -1 ro...@debian.org Bug #854508 [wnpp] ITP: node-hash-base -- abstract base class for hash-streams Owner changed from Shirish Togarla to ro...@debian.org. -- 854508: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854508 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#853722: I take it
control: owner -1 ro...@debian.org
Processed: I take it
Processing control commands: > owner -1 ro...@debian.org Bug #853722 [wnpp] ITP: node-subarg -- parse arguments with recursive contexts Owner changed from akash to ro...@debian.org. -- 853722: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853722 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#860843: ITP: node-string-decoder -- The string_decoder module from Node core
package: wnpp Severity: wishlist Owner: Bas Couwenberg * Package name: node-string-decoder Version : 0.10.25 Upstream Author : Rod Vagg * URL : https://github.com/rvagg/string_decoder * License : Expat Programming Lang: JavaScript Description : The string_decoder module from Node core node-string-decoder provides the string_decoder module from Node.js core for browsers. node-string-decoder is required for node-readable-stream (#761442) which in turn is required for node-decompress-zip (#779498). The node-string-decoder package will be maintained in the JavaScript team. This is a reintroduction due to browser needing verbatim for one package of browserify
Processed: owner 860843
Processing commands for cont...@bugs.debian.org: > owner 860843 Bastien ROUCARIES Bug #860843 [wnpp] ITP: node-string-decoder -- The string_decoder module from Node core Owner changed from Bas Couwenberg to Bastien ROUCARIES . > thanks Stopping processing here. Please contact me if you need assistance. -- 860843: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860843 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#835654: [Pkg-net-snmp-devel] Orphaning net-snmp?
I tried taking over this but the alioth permissions were wrong and admin is unresponsive. - Craig On Fri, 21 Apr. 2017, 02:12 Adrian Bunk, wrote: > Control: retitle -1 O: net-snmp -- SNMP configuration script, MIBs and > documentation > > Thanks to everyone for answering, I hereby orphan net-snmp. > > On Mon, Feb 27, 2017 at 02:08:16PM +0100, Jochen Friedrich wrote: > > Yes, +1 > > > > > > Am 22.01.2017 um 16:01 schrieb Noah Meyerhans: > > > On Sun, Jan 22, 2017 at 11:19:46PM +0900, Hideki Yamane wrote: > > > > > Since the #835654 RFH didn't result in new members joining the > team, > > > > > would it be OK if I orphan the package to make it clear that there > > > > > is no maintainer and that anyone can make a QA upload without > delay? > > > > I've already stepped down from uploaders, so if Jochen would agree > > > > with it, it should be orphaned. > > > I'm listed in Uploaders but > > > a) I'm not using net-snmp actively anywhere; and > > > b) The only uploads I ever did were targeting stable-security, and I > > > was never active in general package maintenance. > > > > > > So, +1 to orphan. > > > > > > noah > > 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 > > > ___ > Pkg-net-snmp-devel mailing list > pkg-net-snmp-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-net-snmp-devel > -- Craig Small (@smallsees) http://dropbear.xyz/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Processed: Whitespace fix for the zfec ITA bug title
Processing commands for cont...@bugs.debian.org: > retitle 859186 ITA: zfec -- fast erasure codec with python bindings Bug #859186 [wnpp] ITA: zfec -- fast erasure codec with python bindings Changed Bug title to 'ITA: zfec -- fast erasure codec with python bindings' from 'ITA: zfec -- fast erasure codec with python bindings'. > thanks Stopping processing here. Please contact me if you need assistance. -- 859186: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859186 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Add owner to the gsignond ITP
Processing commands for cont...@bugs.debian.org: > owner 831747 Corentin Noël Bug #831747 [wnpp] ITP: gsignond -- gSSO daemon and default plugins Owner recorded as Corentin Noël . > thanks Stopping processing here. Please contact me if you need assistance. -- 831747: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831747 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems