Package: wnpp
Severity: wishlist
Owner: Xavier Guimard
* Package name: psl.js
Version : 1.2.0
Upstream Author : Lupo Montero
* URL : https://github.com/lupomontero/psl
* License : Expat
Programming Lang: JavaScript
Description : JavaScript domain name
On Tuesday 16 July 2019 23:11:24 Florian Weimer wrote:
> * Nicholas D. Steeves:
> > Package name: fuidshift
> > Version : 3.0
> > Upstream Author : Name
> > URL : https://github.com/lxc/lxd/tree/master/fuidshift
> > License : Apache 2.0
> > Programming Lang: Go
> >
On July 16, 2019 3:37:04 PM UTC, Russ Allbery wrote:
>Scott Kitterman writes:
>
>> Except that we have different requirements than git. Git isn't
>looking
>> for security properties from SHA-1, so it's highly likely it'll meet
>> their accident avoidance requirements long after it's no longer
On Tue, 2019-07-16 at 11:57 +0200, Raphael Hertzog wrote:
[...]
> The other desktop firewall that I know is "ufw" but it doesn't seem to
> have any momentum behind it.
Also, while its syntax is obviously intended to be simple, it's quite
irregular and the syntax error messages aren't very helpful.
* Nicholas D. Steeves:
> Package name: fuidshift
> Version : 3.0
> Upstream Author : Name
> URL : https://github.com/lxc/lxd/tree/master/fuidshift
> License : Apache 2.0
> Programming Lang: Go
> Description : remap a filesystem tree to shift one set of UID/GID
> ra
Package: wnpp
Severity: wishlist
Owner: William Grzybowski
* Package name: py-libzfs
Version : 0.1
Upstream Author : FreeNAS
* URL : https://github.com/freenas/py-libzfs
* License : BSD-3-Clause
Programming Lang: Python
Description : Python libzfs bindi
On 09.07.19 09:32, Marc Haber wrote:
> It is good to know where things are going. Would you mind if I created
> a wiki page with this road map laid out about where Debian's cron
> world is going?
Not at all, on the contrary -- thanks for the offer!
> That would, though, only make sense if you cou
Package: wnpp
Severity: wishlist
Owner: William Grzybowski
* Package name: bidict
Version : 0.18.0
Upstream Author : Joshua Bronson
* URL : https://bidict.readthedocs.io/
* License : MPL-2.0
Programming Lang: Python
Description : Efficient, Pythonic bi
Hello,
On Tue 16 Jul 2019 at 10:45AM +02, Ansgar Burchardt wrote:
> A "source package" generally consists of:
> - a set of upstream artifacts (currently one or more tarballs,
>signatures); can be the empty set for native packages
> - Debian-specific artifacts
> - the .dsc artifact (generat
Hello,
On Tue 16 Jul 2019 at 08:37AM -07, Russ Allbery wrote:
> The consensus among all of us was that if you have an opportunity to pick
> something other than SHA-1 when designing a new protocol, you should. But
> if it's not simple to pick a different hash, SHA-1 preimage resistance is
> reas
Scott Kitterman writes:
> Except that we have different requirements than git. Git isn't looking
> for security properties from SHA-1, so it's highly likely it'll meet
> their accident avoidance requirements long after it's no longer
> appropriate for security related assertions.
> I don't thin
On Tue, Jul 16, 2019 at 7:00 PM Javeed Ahmed wrote:
> can i make my own os using debian as a base and distribute it?
Yes, but you can also join the Debian project and help us improve the
Debian operating system for your use-cases.
Would you like to share your plans for how you want to change th
On Tue, Jul 16, 2019 at 9:44 AM Kyle Edwards
wrote:
>
> On Tue, 2019-07-16 at 10:22 +, Javeed Ahmed wrote:
> > sir/madam
> > can i make my own os using debian as a base and distribute it?
>
> Absolutely! Debian is free software, and you are free to use, modify,
> and distribute it for any pur
On Tue, 2019-07-16 at 10:22 +, Javeed Ahmed wrote:
> sir/madam
> can i make my own os using debian as a base and distribute it?
Absolutely! Debian is free software, and you are free to use, modify,
and distribute it for any purpose. Please make sure to follow the rules
of each package's licen
sir/madamcan i make my own os using debian as a base and distribute it?
On 7/16/19 11:57 AM, Raphael Hertzog wrote:
> Hi,
>
> I'm replying to your questions but I have also other questions related to
> this fresh transition...
>
> On Tue, 16 Jul 2019, Arturo Borrero Gonzalez wrote:
>> as you may know, Debian 10 buster includes the iptables-nft utility by
>> default,
Hi,
I'm replying to your questions but I have also other questions related to
this fresh transition...
On Tue, 16 Jul 2019, Arturo Borrero Gonzalez wrote:
> as you may know, Debian 10 buster includes the iptables-nft utility by
> default,
> which is an iptables flavor that uses the nf_tables ker
Hi!
On Tue, 2019-07-16 at 11:07:15 +0200, Arturo Borrero Gonzalez wrote:
> as you may know, Debian 10 buster includes the iptables-nft utility by
> default, which is an iptables flavor that uses the nf_tables kernel
> subsystem. Is intended to help people migrate from iptables to nftables.
Yeah,
Hi there,
as you may know, Debian 10 buster includes the iptables-nft utility by default,
which is an iptables flavor that uses the nf_tables kernel subsystem.
Is intended to help people migrate from iptables to nftables.
For the next release cycle I propose we move this default event further.
As
Hi Sean,
On 15.07.19 19:02, Sean Whitton wrote:
> On Mon 15 Jul 2019 at 01:16PM +02, Michael Kesper wrote:
>
>> Nonetheless it seems to me you are moving from trusting local signing
>> to trusting upload by salsa, thereby making salsa more attractive for
>> attackers.
>
> I don't follow -- the g
On Tue, 2019-07-16 at 08:29 +0100, Sean Whitton wrote:
> We also rely on git for security elsewhere. For example, dak is
> deployed by ftpmasters pushing a signed git tag to salsa; a cronjob on
> ftpmaster then deploys that code. That's relying on SHA-1 in pretty
> much the same way as tag2upload
Hello,
On Mon 15 Jul 2019 at 12:47PM -07, Russ Allbery wrote:
> I'm dubious that we really care that much about a preimage attack on
> SHA-1, [...]
Someone suggested on IRC that such an attack on tag2upload is even less
likely to be possible because each preimage has to be something which
dpkg-s
On 15.07.19 22:50, Russ Allbery wrote:
> At some point, Git itself will switch away from SHA-1, and we
> can then obviously follow.
According to [0]:
-
"Git v2.13.0 and later subsequently moved to a hardened SHA-1
implementation by default, which isn't vulnerable to the SHAttered
attack.
Thu
23 matches
Mail list logo
