Processed: Add owner to the gsignond ITP

[Debian Bug Tracking System]

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

Processed: Whitespace fix for the zfec ITA bug title

[Debian Bug Tracking System]

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

Bug#835654: [Pkg-net-snmp-devel] Orphaning net-snmp?

[Craig Small]

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: owner 860843

[Debian Bug Tracking System]

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#860843: ITP: node-string-decoder -- The string_decoder module from Node core

[Bastien ROUCARIES]

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: I take it

[Debian Bug Tracking System]

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#853722: I take it

[Bastien ROUCARIES]

control: owner -1 ro...@debian.org

Processed: No activity

[Debian Bug Tracking System]

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#854508: No activity

[Bastien ROUCARIES]

control: owner -1 ro...@debian.org

Hi,

Without ctivity I take this bug report

Bug#858458: marked as done (ITP: lbry -- A fully decentralized network for distributing data)

[Debian Bug Tracking System]

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 ---

Processed: highwayhash: block ITP 848885 by RFS 860804

[Debian Bug Tracking System]

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#726668: dtmf2num

[Alex Myczko]

Hello Dominik

If you're still missing the package, here it is (not completely ready, 
but working):

http://sid.ethz.ch/debian/dtmf2num/

Yours,

Bug#860771: ITP: node-diffie-hellman -- pure js diffie-hellman

[Christian Seiler]

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#860116: [Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager

[Luca BRUNO]

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#860116: [Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager

[Josh Triplett]

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#860771: ITP: node-diffie-hellman -- pure js diffie-hellman

[Bastien ROUCARIES]

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

[Ximin Luo]

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