Sven Hoexter: Debian and exFAT
As some might have noticed we now have Linux 5.7 in Debian/unstable and
subsequently the in kernel exFAT
implementation created by Samsung available. Thus we now have two exFAT
implementations, the
exfat fuse driver
and the Linux based one. Since some comments and mails I received showed
minor confusions, especially around the available tooling, it might help
to clarify a bit what is required when.
Using the Samsung Linux Kernel Implementation
Probably the most common use case is that you just want to use the
in kernel implementation. Easy, install a Linux 5.7 kernel package
for your architecture and either remove the
exfat-fuse package
or make sure you've version 1.3.0-2 or later installed. Then
you can just run mount /dev/sdX /mnt and everything should be fine.
Your result will look something like this:
$ mount grep sdb
/dev/sdb on /mnt type exfat (rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro
mount.exfat
helper, which was just a symlink to the helper which is shipped
as /sbin/mount.exfat-fuse. The link was dropped from the package
in 1.3.0-2. If you're running a not so standard setup, and would
like to keep an older version of exfat-fuse installed you must
invoke mount -i to prevent mount from loading any helper to mount
the filesystem. See also
man 8 mount.
For those who care, mstone@ and myself had a brief discussion
about this issue in
#963752,
which quickly brought me to the conclusion that it's in the best interest
of a majority of users to just drop the symlink from the package.
Sticking to the Fuse Driver
If you would like to stick to the fuse driver you can of course just do it.
I plan to continue to maintain all packages for the moment. Just keep the
exfat-fuse package installed and use the mount.exfat-fuse helper
directly. E.g.
$ sudo mount.exfat-fuse /dev/sdb /mnt
FUSE exfat 1.3.0
$ mount grep sdb
/dev/sdb on /mnt type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
mount.exfat symlink pointing at the
mount.exfat-fuse helper.
mkfs and fsck - exfat-utils vs exfatprogs
Beside of the filesystem access itself we now also have two implementations
of tooling, which support filesystem creation, fscking and label adjustment.
The older one is exfat-utils
by the creator of the fuse driver, which is also part of Debian since the
fuse driver was packaged in 2012. New in Debian is the
exfatprogs package
written by the Samsung engineers. And here the situation starts to get
a bit more complicated.
Both packages ship a mkfs.exfat and fsck.exfat tool, so we can not
co-install them. In the end both packages declare a conflict with each
other at the moment. As outlined in
this thread I do not plan to overcomplicate the situation by using
the alternatives system. I do feel strongly that this would just create
more confusion without a real benefit. Since the tools do not have
matching cli options, that could also cause additional issues and confusion.
I plan to keep that as is, at least for the bullseye release. Afterwards
it's possible, depending on how the usage evolves, to drop the
mkfs.exfat and fsck.exfat from exfat-utils, they are in fact
again only symlinks. pain point might be tools interfacing with the
differing implementations. Currently I see only three reverse depedencies,
so that should be manageable to consolidate if required.
Last but not least it might be relevant to mention that the exfat-utils
package also contains a dumpexfat tool which could be helpful if you're
more into forensics, or looking into other lower level analysis of an exFAT
filsystem. Thus there is a bit of an interest to have those tools co-installed
in some - I would say - niche cases.
buster-backports
Well if you use buster with a backports kernel you're a bit on your own.
In case you want to keep the fuse driver installed, but would still like to
mount, e.g. for testing, with the kernel exFAT driver, you must use mount -i.
I do not plan any uploads to buster-backports. If you need a mkfs.exfat
on buster, I would recommend to just use the one from exfat-utils for
now. It has been good enough for the past years, should not get sour
before the bullseye release, which ships exfatprogs for you.
Kudos
My sincere kudos go to:
- Andrew Nayenko who wrote the exFAT fuse implemetation which was very helpful to many people for the past years. He's a great upstream to work with.
- Namjae Jeon and Hyunchul Lee who maintain the Linux exFAT driver and exfatprogs. They are also very responsive upstreams and easy to work with.
- Last but not least our ftp-master who reviewed the exfatprogs package way faster than what I had anticipated looking at the current NEW backlog.
Nearly a year ago people starting worrying about the complexity of SHA-1 being reduced and the potential availability of viable attacks against things such as PGP keys that used SHA-1. Many people (myself included) generated a new key, or updated preferences on keys that were otherwise strong enough. There were worries about what this might mean for Debian. We were getting ahead of ourselves a bit though. Firstly there haven't been any public viable attacks that I'm aware of (though of course this doesn't mean we shouldn't continue to migrate away), but secondly there's a much easier method of attack. PGP v3 keys. To quote 
So Avi Bryant finally 