Re: deb.debian.org [was: Re: howto avoid "apt-get update" going guru?]

[Tollef Fog Heen]

]] 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 or documentation of this, other than
> > > that on the site itself, though I did find a use of it in a recent
> > > announcement of dbgsym packages.
> > 
> > It's somewhat in beta yet.  I should probably write up an announcement
> > about it.
> 
> Ah, that makes sense.  I look forward to the announcement.
> 
> When you make the announcement, can you include a link to the details of
> the CDN, such as the extent of its caching servers?  That would help
> people determine if using it will likely produce good results for them.

Yeah, though what you actually want to check is whether it is faster for
them or not, rather than base it on just geographical distance.

> > > Does the CDN this uses download and cache packages on first request?
> > > Because I noticed when testing it that if I requested a package
> > > reasonably unlikely to have already been fetched, it would hang at "0%
> > > [Waiting for headers]" for a long time (minutes).  But if I reattempted
> > > that same package later, it would download just fine.
> > 
> > This was a bug and should be fixed now.  (It downloads on first request,
> > but it streams, so there should not be a big initial delay.)
> 
> Out of curiosity, what was the bug?

A bug in the VCL generator which caused an early return before
the flag to enable streaming was set.  I added a workaround which makes
it so we no longer hit the bug.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

So I received a gpg-signed email, can I trust it?

[Enrico Zini]

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 automate
it", I'd like to begin with a simple use case:

  So I received a gpg-signed email, can I trust it?

I'll write here my take on it and request your comments on it, to see if
there are any gaps.

Take for example this file, and an empty keyring:

  $ mkdir /tmp/keyring
  $ chmod 0700 /tmp/keyring
  $ echo "keyserver hkp://keys.gnupg.net" >> /tmp/keyring/gpg.conf
  $ cat /tmp/testmessage
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
  
  Fri Jul  8 11:03:02 CEST 2016: this is a test message
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1
  
  iQIcBAEBCAAGBQJXf2xGAAoJEAPWVoyDcnWpzsoP/Aiw9y3D7qM/8aIjTuTakXG1
  dbDi/7lIrWx2bvFFVAFY27q9l6UKF97nXym28ceatpPhYyeuUbSms12btY3kQ796
  nEF81oLIHonayD6QOOSj2SrJIgl2B5oYSg/fxsq+bUBmcY9T3aHPsgGlSU7+to2b
  ohv9D/Big3H2hWx0PPfhnLsCXLcNXFmUt83hsrrgUQvRA9oh7FjKBjbOYyLd4hBN
  ejvnaf5PWuhPfWtK1mMpTEExn6V5i498+PxGojXLzapbtGEcybqfdvqlbtqii2LP
  0dg4UwPnGdzZPUHHRbUwslLoPRb9KCspxlAE1U707NH+4Y3/4GMi/lhnfp/qxpMF
  OKey0STi1pIJbn5SbG5GHlQD+1zbypelr4UnvOEZsYNcxkN1iduA5jL4IreQ2KqU
  d/bVplK1w9i766ZgLI69A1TuRneKiRJTNur0UOwQZv0zonlGhIlSKi1IoMCtrKtN
  jXTwALyUj5xUyNYAwqwR9I93wAcVVWzJbHB6DSCYa11AIkZV7Lnvz6A+dcNOdX21
  3mhsjRqM5U28fBk5pdGj/MkjJyL4aegmzFBiImUQtV8gIL5HGmI2yxlLvIEx7O7z
  PUrOKZLrHflCZ0kZOty5njnZ2ep2rRQNEdT4mD8SuKKt6vfpQdzUQxTZoRgOHYA2
  Skl15idSonqVP370zzDf
  =DKdd
  -END PGP SIGNATURE-

gpg --verify tells me of a short key ID:

  $ gpg2 --homedir /tmp/keyring/ --verify /tmp/testmessage 
  gpg: keybox '/tmp/keyring//pubring.kbx' created
  gpg: Signature made Fri 08 Jul 2016 11:03:02 CEST using RSA key ID 837275A9
  gpg: Can't check signature: No public key

I can switch to long key IDs, but I still get something that can match
multiple keys:

  $ echo "keyid-format long" >> /tmp/keyring/gpg.conf
  $ gpg2 --homedir /tmp/keyring/ --verify /tmp/testmessage
  gpg: Signature made Fri 08 Jul 2016 11:03:02 CEST
  gpg:using RSA key 03D6568C837275A9
  gpg: Can't check signature: No public key

So let's assume long key IDs give me only a false sense of security and
go ahead without "keyid-format long". I'll download the key used to sign
the message:

  $ gpg2 --homedir /tmp/keyring/ --recv 837275A9
  gpg: /tmp/keyring//trustdb.gpg: trustdb created
  gpg: key E7AD5568: public key "Enrico Zini " imported
  gpg: no ultimately trusted keys found
  gpg: Total number processed: 1
  gpg:   imported: 1

In this case I've been lucky, because there were no collisions on the
short key ID of my signing subkey, but I cannot rely on having only the
right key in the keyring at this point. For example:

  $ gpg2 --homedir /tmp/keyring/ --recv A7457645
  gpg: key A7457645: public key "Piotr Ozarowski " imported
  gpg: key A7457645: public key "Piotr Ozarowski " imported
  gpg: no ultimately trusted keys found
  gpg: Total number processed: 2
  gpg:   imported: 2

Now I have one or more keys, I can verify the message:

  $ gpg2 --homedir /tmp/keyring/ --verify /tmp/testmessage 
  gpg: Signature made Fri 08 Jul 2016 11:03:02 CEST using RSA key ID 837275A9
  gpg: Good signature from "Enrico Zini " [unknown]
  gpg: aka "Enrico Zini " [unknown]
  gpg: aka "Enrico Zini " [unknown]
  gpg: aka "Enrico Zini " [unknown]
  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:  There is no indication that the signature belongs to the owner.
  Primary key fingerprint: 1793 D6AB 7566 3E6B F104  953A 634F 4BD1 E7AD 5568
   Subkey fingerprint: 1CC0 1267 007F ABE6 5846  6857 03D6 568C 8372 75A9

gpg2 tells me that the signature is Good (that is, the message is the
same that has been signed and has not been tampered with), and it has
been verified as having been made with the key 
1793D6AB75663E6BF104953A634F4BD1E7AD5568.

I know that the message hasn't been tampered with, but it can still be a
message from the attacker that generated the colliding key, so now I
neeed to find out what I can tell about the owner of key
1793D6AB75663E6BF104953A634F4BD1E7AD5568. I made an attempt at this at
http://www.enricozini.org/blog/2016/debian/verifying-gpg-keys/


Enrico

[1] https://evil32.com/
[2] https://www.ietf.org/mail-archive/web/openpgp/current/msg07195.html
https://github.com/coruus/cooperpair
-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: deb.debian.org [was: Re: howto avoid "apt-get update" going guru?]

[Josh Triplett]

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, thanks!  Seems to have decent performance.
> > 
> > Ah, that makes sense.  I look forward to the announcement.
> > 
> > When you make the announcement, can you include a link to the details of
> > the CDN, such as the extent of its caching servers?  That would help
> > people determine if using it will likely produce good results for them.
> 
> The locality of this CDN seems to be... not the best.
> 
> In Poland, there's 11 mirrors (according to choose-mirror 2.69), and
> httpredir.debian.net always gives me one of those.  Not the closest one
> network- or geography- wise, but in a country the size of Poland, that's
> good enough.
> 
> deb.debian.org on the other hand, trying from two locations over three ISPs:
> Starogard Gdański/Netia, Starogard Gdański/UPC, Gdańsk/Limes:
> * IPv6: Amsterdam or London
> * IPv4: MIT, San Francisco, London

Just to confirm, did you use SRV records for this check as apt does, or
did you check the path to deb.debian.org's A or  records directly?

If I ping deb.debian.org directly, it resolves to various mirrors,
with ping times ranging from 20ms to 200ms away.  The SRV records,
though, point to a CDN server that reliably gets 20ms.

(I don't actually know the benefit of using SRV records here.)

- Josh Triplett

Bug#830475: ITP: r-cran-treescape -- GNU R Statistical Exploration of Landscapes of Phylogenetic Trees

[Andreas Tille]

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 : GPL
  Programming Lang: GNU R
  Description : GNU R Statistical Exploration of Landscapes of Phylogenetic 
Trees
 This GNU R package provides tools for the exploration of distributions
 of phylogenetic trees. This package includes a shiny interface which can
 be started from R using 'treescapeServer()'.


Remark: Finally all preconditions for this tip of the iceberg are ready.
The package will be maintained by the Debian Med team at
   svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-treescape/trunk/

Re: So I received a gpg-signed email, can I trust it?

[Jakub Wilk]

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


$ mkdir -m 0700 foobar


And you really shouldn't use /tmp as a personal scratch space.
/tmp is word-writable and therefore not suitable for this purpose.

(Yes, I realize that these are just examples. But let's not teach people 
bad habits.)


--
Jakub Wilk

Request for help - faithful source format (related to dgit)

[Ian Jackson]

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 source package
representations, for non-native packages, is that none of them
represent deletions of files which are present in upstream tarball(s)
but which the maintainer deletes (or wishes to delete).

This causes especial trouble for dgit.  (See dgit(7).)

I would like to see a better solution to this, preferably in stretch.
I think this is still possible.  I started an attempt but I got
slightly discouraged by some unexpected qualms in some quarters.  And
I have substantial amounts of other dgit work to do (notably, sane
handling of gbp git trees), so I am not going to be able to put in the
time to fix this properly for stretch.

Is there anyone who would like to help with this ?


Solution-neutral problem statement:

 * The primary objective is to be able to represent any tree (let us
   say, anything which is representable as a git "tree object") as a
   Debian source package, while still retaining the space/bandwidth
   and traceability advantages of basing the source package on
   upstream tarballs.

 * So there should be a non-native source format which is capable of
   accurately representing at least any git-representable tree, as
   `differences' from any source tarballs.

 * "Accurately" means that it must represent:
 - changes to executableness of files
 - files present in upstream but removed in Debian
 - replacement of a directory with a file or vice versa
 - symlinks
 - removal of "unusual" filesystem objects such as fifos,
   sockets, devices, or whatever (which some upstream
   tarballs ship)
 - creating, deletion and changes to binary files (ideally,
   efficiently representing small changes to big binaries)

 * This format should be available in a patch-stack-less version, at
   the very least.

 * This format should support multiple orig tarballs in the same way
   as `3.0 (quilt)'.

 * Ideally this would be in stretch and backportable to jessie or
   even earlier.

 * It is NOT a requirement that `the same changes' (as represented by
   whatever actual container file - .diff or .rsync or whatever- ends
   up being in the source package), can be applied to different
   upstream tarballs.  The assumption is that maintainers who use this
   format will use other means (eg, a version control system) to
   rebase the Debian changes onto a new upstream.


Stakeholders:

 * The dpkg maintainers (CC'd) obviously have a big stake in this
   and their support will be essential

 * ftpmaster will need to support the new format too

 * Consultation with the wider community of Debian contributors, and
   derivatives, would be helpful, but should not be allowed to block.


Technical ideas:

 * rsync batch mode provides a stable binary format, and rsync is
   extremely reliable software of exceptional quality and stability.
   rsync has a very good history of backward-compatibility.

   A format a bit like 1.0 but supporting multiple tarballs and
   replacing the .diff.gz with a .rsync.gz (with a specified rsync
   protocol version, to ensure compatibility) would work.

   I proposed this some time last year.  ftpmaster were concerned that
   they would lose an easy way to view the diff between upstream and
   Debian; so, this approach would require some kind of update to the
   ftpmaster tools.

   If a patch stack version is wanted, the .debian.tar.gz could be
   replaced by a .rsync.gz which creates debian/patches/* along with
   whatever other changes are wanted.  This may be confusing, because
   not every Debian change would be in debian/patches/.

 * There has been talk of using advanced GNU diff/patch features.  I
   am rather sceptical of these because they are very new, and because
   diff and patch have a rather poor history in backward compatibility
   terms.

   Also it may be difficult to control exactly which diff/patch
   features end up being used.  This has already caused some lossage,
   where a new not-backward-compatible source sub-format was
   accidentally introduced into our archive (!)

One part of the task I need help with is negotiating and selecting an
appropriate technical approach.


Thanks for your attention.

Ian.


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: So I received a gpg-signed email, can I trust it?

[Simon Richter]

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 web of trust, in principle there shouldn't be a problem.

I have a valid trust path to Piotr's correct key. I don' have any to the
fake key, because no one I trust has signed a key from the evil32 set.

What could be improved would be detection of new signatures under fake
keys. I've filed Debian bug #830479 about a possible solution.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: So I received a gpg-signed email, can I trust it?

[Enrico Zini]

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 and tools.
> 
> With the web of trust, in principle there shouldn't be a problem.
> 
> I have a valid trust path to Piotr's correct key. I don' have any to the
> fake key, because no one I trust has signed a key from the evil32 set.

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?


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: So I received a gpg-signed email, can I trust it?

[Jakub Wilk]

* 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 principle there shouldn't be a problem.

I have a valid trust path to Piotr's correct key. I don' have any to 
the fake key, because no one I trust has signed a key from the evil32 
set

...yet.

Given that many crypto tools have --feel-free-to-shoot-me-in-the-foot as 
the default, and some even don't have --do-not-shoot-me-in-the-foot as 
an option (see #800134), it's only a matter of time before someone slips 
up.


Or maybe it's already happened? Check out debian-hiding-problems@, er, I 
mean debian-private@ archives.


--
Jakub Wilk

Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[german398]

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 Stable and it says 
that btrfs is under heavy development and isn't suitable for any uses other 
than benchmarking and review. Proof-link: 
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/filesystems/btrfs.txt?id=refs/tags/v3.16.36


I'm really confused, I don't know whom to believe.

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[YunQiang Su]

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 documentation for version of a Linux kernel of Debian 
> Stable and it says that btrfs is under heavy development and isn't suitable 
> for any uses other than benchmarking and review. Proof-link: 
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/filesystems/btrfs.txt?id=refs/tags/v3.16.36

Believe the upstream.
While in the nearest kernel, there is no sentence about "under heavy
development".
Installer is just installer.

>
>
> I'm really confused, I don't know whom to believe.
>



-- 
YunQiang Su

Re: So I received a gpg-signed email, can I trust it?

[Guilhem Moulin]

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 ultimately trusted keys found
gpg: Total number processed: 1
gpg:   imported: 1
gpg: Good signature from "Enrico Zini " [unknown]
gpg: aka "Enrico Zini " [unknown]
gpg: aka "Enrico Zini " [unknown]
gpg: aka "Enrico Zini " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the 
owner.
Primary key fingerprint: 1793 D6AB 7566 3E6B F104  953A 634F 4BD1 E7AD 5568
 Subkey fingerprint: 1CC0 1267 007F ABE6 5846  6857 03D6 568C 8372 75A9

> I can switch to long key IDs, but I still get something that can match
> multiple keys:

64-bits key IDs are indeed vulnerable to collision attacks, but unlike
their 32-bits counterparts they are not known to be vulnerable to
preimage attacks.  Thus long key ID impersonation is not known to be
possible at this point.

The OpenPGP Working Group is currently discussing an RFC 4880 revision
[1].  In particular, a new “Issuer Fingerprint” subpacket has been
proposed to deprecate the issuer subpacket and store full issuer
fingerprints rather than key IDs in OpenPGP signatures.

https://mailarchive.ietf.org/arch/msg/openpgp/LFtg4NzKEHIa8qTa4F0t7mr3JJQ

This would solve the problem of key impersonation if preimage attacks
become practical on 64-bits key IDs in the future, as
‘--keyserver-options=auto-key-retrieve’ would then be able to query the
issuing key based on its fingerprint not its (possibly colliding)
64-bits key ID.  Moreover, I hope this would also make gpg able to
import two different keys colliding on their 64-bits key ID, which
currently fails (as keys are indexed by their 64-bits key ID ;-)

Cheers,
-- 
Guilhem.

[0] https://tools.ietf.org/html/rfc4880#section-5.2.3.5
[1] https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis


signature.asc
Description: PGP signature

Bug#830499: ITP: ncrack -- High-speed network authentication cracking tool

[Marcos]

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

It was built to help companies secure their networks by proactively testing all
their hosts and networking devices for poor passwords. Security professionals
also rely on Ncrack when auditing their clients. Ncrack was designed using a
modular approach, a command-line syntax similar to Nmap and a dynamic engine
that can adapt its behaviour based on network feedback. It allows for rapid,
yet reliable large-scale auditing of multiple hosts.

Ncrack’s features include a very flexible interface granting the user full
control of network operations, allowing for very sophisticated bruteforcing
attacks, timing templates for ease of use, runtime interaction similar to
Nmap’s and many more. Protocols supported include RDP, SSH, http(s), SMB,
pop3(s), VNC, FTP, and telnet.

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[Steve McIntyre]

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 a Linux 
>kernel of Debian Stable and
>it says that btrfs is under heavy development and isn't suitable for any uses 
>other than benchmarking
>and review. Proof-link:
>https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/filesystems/btrfs.txt?id=refs/tags/v3.16.36
>
>I'm really confused, I don't know whom to believe.

The installer allows lots of choices of things, not all of them are
recommended. But enough people find value in being able to play with
things like btrfs that we make it easy for people to do that. If you
want a stable system with sensible options, the defaults suggested in
the Debian installer will work fine for the vast majority of users.

As an aside: I *personally* don't want to use btrfs for anything at
all yet and wouldn't recommend it.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?

Re: So I received a gpg-signed email, can I trust it?

[Holger Levsen]

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 things than a signed message. I
have traveled to other continents based on unsigned text messages,
because I could trust the contents (via other means than validating
signatures.)

so whether I would trust stuff signed by 0x44BB1BA79F6C6333 also
depends on the content of the message…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[Henrique de Moraes Holschuh]

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 choices are ext4 and XFS.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[Russ Allbery]

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 very
> conservative on these matters, your two choices are ext4 and XFS.

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

Some of those bugs have been patched in XFS implementations in newer
kernels, but I think ext4 is a better conservative choice given the
history.

-- 
Russ Allbery (r...@debian.org)   

Bug#830512: ITP: python-django-navtag -- Django template tag to handle navigation

[Michael Fladischer]

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-3-clause
  Programming Lang: Python
  Description : Django template tag to handle navigation


 A simple Django template tag to handle navigation item selection. It works
 through template inheritance and allows to define hierarchical navigation menu
 structures in the presentation layer. It differentiates itself from other
 solutions by sole reliance on templates.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXgAdFAAoJEGlMre9Rx7W2v1wP/jrPB3Ha3LV7iQa1KQ0mFTXl
Ml7yiSzwJ07E+lBCLj+8NVIcKhUqhCUYt3WFV3kkrDm0Dt2Rf+ZPkG0R4LkQO61r
yuaVn3iLcWmm92zPzf7kpDMiES1uNZ5gY2rNVQyhFh2Bbzbn7cxhthNr1CMNd9zh
geZfTqnG4mlak2sYGmTxElUl19HyCMJfr9kiMnAppmAUAzyHWafRpaNRlV8JE0tf
X6GAHUoZjlSIOCYSji/bYWTSA9ELry75sLp5dxBg1Hf1/nWgU6x4JWu1Zewr/VE6
BaCJbTBNlRueZx2tYEQvrdh/aLvD0Odd1QX0Bw+wwVGh71oJ14oqp7YWTmSDb1aS
UlaawTnJCsdlonT+a5xbqr3ixz3Hqzxtc+7KCGSd8dRyw/O3Wsz+uQ3/7v8d1PjC
zA8uCBbJS3N5TTPwqrzAIMSSAFhbta6Sko/8ZujRqkucGHuD3DsN/4QpC1ryEV93
qVRE0usRnh8pqBLp3qGTmZJ3EIBHemnIvC5Cb5kexq14QsTGV/7VMGhD8kjQi2xA
jfQnI8aF/TKdS72sJ0CpHrZwEre4KZLGeT72+I1HPjEgVerzBRaY+loa95sIj7P3
WF6HLsIbhCMXbzAyJ53JdvLgVQQnmJjX714LIdyx1U0CY821Ion7j504XDDguQ6G
XJD2nuirOk62hXAlz6zt
=6pIa
-END PGP SIGNATURE-

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[Marco d'Itri]

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 ext4.
I mostly agreed with this, but then Red Hat switched to XFS as their 
default and I consider this a significant endorsement.
Nowadays I tend to use XFS for the larger (> 500 GB) file systems.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[Dimitri John Ledkov]

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 documentation for version of a Linux kernel of Debian 
> Stable and it says that btrfs is under heavy development and isn't suitable 
> for any uses other than benchmarking and review. Proof-link: 
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/filesystems/btrfs.txt?id=refs/tags/v3.16.36
>
>
> I'm really confused, I don't know whom to believe.
>

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. In stress testing, and compliance testing
it's not the best zfs comes out better than btrfs on the linux kernel.
d-i guides one to use sane / general purpose defaults, and at the
moment that is ext4, please use that. xfs is good as well, but I have
not tested it as much as I did ext4/zfs/btrfs.

Please have backups. If you don't have backups start doing them now.

btrfs-tools/-progs package maintainer here.

-- 
Regards,

Dimitri.

ext4 and XFS [was: Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?]

[Josh Triplett]

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 seen any of those problems with ext4.
>
> I mostly agreed with this, but then Red Hat switched to XFS as their
> default and I consider this a significant endorsement.
> Nowadays I tend to use XFS for the larger (> 500 GB) file systems.

I did some research on filesystems for the Software Heritage project, and
looked specifically at ext4 versus XFS, based on the theory that XFS handled
large filesystems better.  Turns out that switching from XFS to a (carefully
tuned) ext4 filesystem decreased storage size and significantly decreased
access latency for SWH's massive repository storage.  Not least of which
because ext4's htree directories work significantly better than XFS's
equivalent.

- Josh Triplett

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[german398]

>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 Stable's 
kernel?
I thought that buggy software isn't included in Debian Stable.

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[german398]

>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 feature. So currently I just 
decided to stick with ext3.

>Then, your case is pretty clear: stay away from brtfs.

How about using ZFS? 

Bug#830525: ITP: golang-github-dghubble-sling -- HTTP client library for creating and sending API requests

[Dmitry Smirnov]

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
URL: https://github.com/dghubble/sling
Description: HTTP client library for creating and sending API requests
 Sling is a Go HTTP client library for creating and sending API requests.


signature.asc
Description: This is a digitally signed message part.

Re: Thinking about a "jessie and a half" release

[Nicholas D Steeves]

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 run Debian
>> that gets them a supported system with an upgrade path.
>
>
> We have Debian Stretch, which is what i recommend to anybody who wants do
> install Debian as a desktop.
>
> I understand the difference of running Debian Testing and Debian Stable with
> some backported packages, but is it really worth it?
> Shouldn't we discuss more the usability of Testing as a solid release, or
> maybe start doing a stable release and another release kinda like Testing
> but with more stability guarantees?
>
> I'm not really sure, but i think opensuse has a model like that.
>
...
> They always end up using Debian Testing, knowing that the main risk comes
> when the unfreeze happens and that while the freeze is rolling they will
> have a more stable debian (compared to when unfreezed).

I personally like to test stable+1 on my laptop by changing stable to
stable+1_codename about a month after the freeze happens; it then
transitions to stable automatically, and no trouble with the unfreeze.
As for building off of a [semi]rolling release model, from testing,
I'm pessimistic because of historical precedents for success.  For
example: http://cut.debian.net/
https://www.reddit.com/r/debian/comments/3yeg6z/what_happened_with_debian_cut/

Tanglu seems to have stalled, and SolydXK is now stable+bpos, but
maybe they will go back to using stable+1 once it freezes? And a
recent discussion on running testing ->
http://forums.debian.net/viewtopic.php?f=30&t=128598&start=0

Of course, I'd also love to see it work! :-)  I'm guessing it requires
a substantial investment of time and a very dedicated—and large
enough—team.

Cheers,
Nicholas

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[german398]

>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 Debian Stable is way older. And btrfs from this particular version of 
Linux kernel seems to be very unreliable. 

So what this highly experimental AND dangerous software is doing in Debian 
Stable? I thought that such software is for Debian Testing and Debian Unstable, 
but not for Debian Stable.

Bug#830526: ITP: golang-github-rogpeppe-fastuuid -- fast generation of 192-bit UUIDs

[Dmitry Smirnov]

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
License: BSD-3-Clause
URL: https://github.com/rogpeppe/fastuuid
Description: fast generation of 192-bit UUIDs
 Package fastuuid provides fast UUID generation of 192 bit universally
 unique identifiers. It does not provide formatting or parsing of
 the identifiers (it is assumed that a simple hexadecimal or base64
 representation is sufficient, for which adequate functionality exists
 elsewhere).


signature.asc
Description: This is a digitally signed message part.

Re: Thinking about a "jessie and a half" release

[Nicholas D Steeves]

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 should be removed there as well.)

Ok, so a very real need for the new radeon driver bpo is/has probably
emerging/ed.  And Bug #828087 on others mentioned in another email to
this thread are blockers to a bpo of xorg-core, which would need to
happen first.

> [...]
>> Also, I imagine this might one day be necessary,
>> particularly if tracking backported linux-src due to ABI changes
>> between kernels, eg: if the out-of-tree drivers in testing begin to
>> require >> linux-src=3.16.0 ABI.
>
> I think you mean API.  We don't ship out-of-tree drivers as binaries.
>

Yes, you're absolutely right, I meant API.  Given that people with,
for example broadcom wifi chipsets will be using this new Debian spin
(Maybe it should be called Debian Fresh Spin?) in the hopes of
hardware enablement, do you think it should pin the bpo versions of
out-of-tree drivers, and also include bpo non-free firmware?

Cheers,
Nicholas

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[Henrique de Moraes Holschuh]

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
data=ordered mode.  It is not widely used, and it has a higher risk of
regressions because of that.

> I tried to use ext4 on Debian Stable due to metadata checksums, but
> then discovered that e2fsck doesn't support this feature. So currently
> I just decided to stick with ext3.

Do yourself a favor and just stick to ext4.

The ext3 kernel driver was put out of its misery due to bitrot, and you
will be using the ext4 driver to run any ext3 filesystem anyway...

> > Then, your case is pretty clear: stay away from brtfs.
> 
> How about using ZFS? 

It would be a choice were you using FreeBSD.  ZFS on Linux is *not*
anywhere close to the same level of stability as native ZFS on FreeBSD
(or ext4/XFS on Linux, for that matter).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

What happened with btrfs during freeze of Debian Jessie?

[german398]

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 says that 
"Btrfs is under heavy development, and is not suitable for
any uses other than benchmarking and review. The Btrfs disk format is not yet 
finalized." (Proof-link: 
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/filesystems/btrfs.txt?id=refs/tags/v3.16.36)
  So it should be expected that btrfs module for this version of Linux kernel 
is very buggy and dangerous. But on the other hand, somehow it managed to 
survive freeze phase and make its way into Debian Stable.

How did it happen ?? O_o