]] Josh Triplett
> [Please CC me on replies.]
>
> Tollef Fog Heen wrote:
> > ]] Josh Triplett
> > > Tollef Fog Heen wrote:
> > > > I personally recommend using deb.debian.org.
> > >
> > > That works nicely, thanks! Seems to have decent performance.
> > >
> > > I couldn't find any announcement
Hello,
given that it is now possible to generate arbitrary short key ID
collisions[1], and that it's now computationally feasible to at least
generate a pair of keys with colliding long key IDs, I'd like to rethink
practices and tools.
In the spirit of "first get to do it, then document it, then
On Fri, Jul 08, 2016 at 08:56:37AM +0200, Adam Borowski wrote:
> On Thu, Jul 07, 2016 at 11:03:16PM -0700, Josh Triplett wrote:
> > Tollef Fog Heen wrote:
> > > ]] Josh Triplett
> > > > Tollef Fog Heen wrote:
> > > > > I personally recommend using deb.debian.org.
> > > >
> > > > That works nicely,
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-treescape
Version : 1.9.17
Upstream Author : Thibaut Jombart, Michelle Kendall, Jacob Almagro-Garcia,
Caroline Colijn
* URL : https://cran.r-project.org/web/packages/treescape/
* License
* Enrico Zini , 2016-07-08, 11:21:
$ mkdir /tmp/keyring
$ chmod 0700 /tmp/keyring
This way of creating a directory inaccessible to other is racy. Between
mkdir and chmod calls, the directory could be opened by an attacker (and
then kept open forever). A non-racy way looks like this:
$ mkd
This is a call for help for one or two volunteers who:
- are keen on gitish (or similar workflows)
- have some time right now
- can speak Perl (as found in dpkg-source)
- are willing and able to do some negotiation as well as coding
Introduction:
One persistent difficulty with our current s
Hi Enrico,
On 08.07.2016 11:21, Enrico Zini wrote:
> given that it is now possible to generate arbitrary short key ID
> collisions[1], and that it's now computationally feasible to at least
> generate a pair of keys with colliding long key IDs, I'd like to rethink
> practices and tools.
With the
On Fri, Jul 08, 2016 at 02:33:54PM +0200, Simon Richter wrote:
> > given that it is now possible to generate arbitrary short key ID
> > collisions[1], and that it's now computationally feasible to at least
> > generate a pair of keys with colliding long key IDs, I'd like to rethink
> > practices a
* Simon Richter , 2016-07-08, 14:33:
given that it is now possible to generate arbitrary short key ID
collisions[1], and that it's now computationally feasible to at least
generate a pair of keys with colliding long key IDs, I'd like to
rethink practices and tools.
With the web of trust, in p
I value stability of a FS over other considerations like shiny new features and
performance. I know that Debian Stable includes only that versions of software
that were considered rock-solid and mostly bug-free. But on the other hand I
read documentation for version of a Linux kernel of Debian S
On Fri, Jul 8, 2016 at 10:55 PM, wrote:
> I value stability of a FS over other considerations like shiny new features
> and performance. I know that Debian Stable includes only that versions of
> software that were considered rock-solid and mostly bug-free. But on the
> other hand I read docum
Hi Enrico,
On Fri, 08 Jul 2016 at 11:21:27 +0200, Enrico Zini wrote:
> gpg --verify tells me of a short key ID:
In fact the issuer subpacket is 8-bytes long [0], hence contains the
long key ID of the signer, as seen using ‘--list-packets’:
~$ gpg --list-packets "
imported
gpg: no ultima
Package: wnpp
Severity: wishlist
Owner: Marcos
* Package name: ncrack
Version : 0.5
Upstream Author : Insecure.Com LLC
* URL : http://nmap.org/ncrack/
* License : GPLv2
Programming Lang: C++
Description : High-speed network authentication cracking tool
german...@ya.ru wrote:
>I value stability of a FS over other considerations like shiny new features
>and performance. I know that
>Debian Stable includes only that versions of software that were considered
>rock-solid and mostly
>bug-free. But on the other hand I read documentation for version of
On Fri, Jul 08, 2016 at 02:54:20PM +0200, Enrico Zini wrote:
> What if you received a message signed with key 9F6C6333?
>
> That is, what do you do (please list the practical steps) to validate a
> signature that is a few steps away from your key in the WoT?
trust in the real world depends on more
On Fri, 08 Jul 2016, german...@ya.ru wrote:
> I value stability of a FS over other considerations like shiny new
> features and performance. I know that Debian Stable includes only that
Then, your case is pretty clear: stay away from brtfs. If you are very
conservative on these matters, your two
Henrique de Moraes Holschuh writes:
> On Fri, 08 Jul 2016, german...@ya.ru wrote:
>> I value stability of a FS over other considerations like shiny new
>> features and performance. I know that Debian Stable includes only that
> Then, your case is pretty clear: stay away from brtfs. If you are v
Package: wnpp
Severity: wishlist
Owner: Michael Fladischer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: python-django-navtag
Version : 2.1.1
Upstream Author : Chris Beaven
* URL : http://github.com/SmileyChris/django-navtag
* License : BSD-
On Jul 08, Russ Allbery wrote:
> And of those two choices, I would lean heavily towards ext4. I have seen
> repeated file system corruptions, kernel panics, and file systems that get
> extremely slow after heavy usage for multiple months under XFS, and have
> not seen any of those problems with
Hello,
On 8 July 2016 at 16:55, wrote:
> I value stability of a FS over other considerations like shiny new features
> and performance. I know that Debian Stable includes only that versions of
> software that were considered rock-solid and mostly bug-free. But on the
> other hand I read docum
Marco d'Itri wrote:
> On Jul 08, Russ Allbery wrote:
> > And of those two choices, I would lean heavily towards ext4. I have seen
> > repeated file system corruptions, kernel panics, and file systems that get
> > extremely slow after heavy usage for multiple months under XFS, and have
> > not see
>Please don't use btrfs. Especially not without understanding fully
what one is getting oneself into. It is checksuming, copy of write
filesystem, however it has degrading over time performance and
stability/recovery issues.
But if btrfs is so unstable, then what the hell it's doing in Debian Sta
>If you are very conservative on these matters, your two choices are ext4 and
>XFS.
I don't want XFS because it has weak journaling compared with "data=journal"
mode of ext3/4.
I tried to use ext4 on Debian Stable due to metadata checksums, but then
discovered that e2fsck doesn't support this
Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Control: block 829461 by -1
Package name: golang-github-dghubble-sling
Version: 1.0
Upstream Author: Dalton Hubble
License: Expat
On 5 July 2016 at 08:40, Samuel Henrique wrote:
>
> 2016-07-05 7:43 GMT-03:00 Jose R R :
>>
>> We're getting to the point where there's a fairly pressing need for
>> arm64 - the more useful hardware is starting to get a wider distribution
>> and we don't really have anything for people who want to
>Believe the upstream. While in the nearest kernel, there is no sentence about
>"under heavy
development". Installer is just installer.
It doesn't matter if the latest stable Linux kernel has stable and mostly
bug-free btrfs. The problem is, that the latest stable Linux kernel for the
latest De
Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Control: block 829461 by -1
Package name: golang-github-rogpeppe-fastuuid
Version: 0.0~git20150106
Upstream Author: Roger Peppe
Licens
On 4 July 2016 at 18:38, Ben Hutchings wrote:
> On Mon, 2016-07-04 at 16:01 -0400, Nicholas D Steeves wrote:
> [...]
> [...]
>> So for radeon hardware enablement, there is 1) the proprietary driver
>
> fglrx is dead upstream and removed from unstable. (It's still in
> jessie-backports, but shoul
On Sat, 09 Jul 2016, german...@ya.ru wrote:
> >If you are very conservative on these matters, your two choices are ext4 and
> >XFS.
>
> I don't want XFS because it has weak journaling compared with "data=journal"
> mode of ext3/4.
The data=journal mode of ext4 is less stable than the default
da
Probably my previous message was misunderstood, so I try to rephrase it.
Current Debian Stable is Debian Jessie. The latest Linux kernel for Debian
Jessie is 3.16. The said version of Linux kernel on the said version of Debian
includes btrfs module. But documentation for this version of kernel s
30 matches
Mail list logo
