On Mon, 2024-04-01 at 10:59 +0200, tho...@goirand.fr wrote:
> Only for the signing operation, one can turn on the "force-sig"
> option so that the key always prompt for a pin. And that is not the
> default.
There are two levels. In the OpenPGP protocol, the smartcard can be
configured to require
Your work is valuable. Many of the things have probably evolved over
time and could use some analysis based on modern cryptography and
security practices. I just wanted to point out that there are subtle
but important differences outside of the key and signature formats.
The most important
Code signing is not equal to code signing. There are a lot of
differences between different code-signing strategies, many of which
are often overlooked.
Example:
I. Typical Windows case
1. Third-party developer gets a key from a CA.
2. Third-party developer signs a program binary.
3. The user
Is rebuilding really the biggest problem? Even if Debian had enough
capacity to rebuild everything after the change of a build dependency,
I do not see how this solves the work of tracking Rust dependencies in
the first place.
I use a handful of Rust applications which I am building myself on
On Sun, 2024-01-14 at 10:47 +0100, Simon Josefsson wrote:
> The more I think about it, I think it seems unfair to categorize this
> as a Go/Rust problem.
The point is that it should be possible all packages in Debian without
dependencies which are outside of Debian.
The same problem exists with
Interesting point in this talk: The APT team is already working on non-
PGP signatures.
https://wiki.debian.org/Teams/Apt/Spec/AptSign
I can see the advantages of that for release signatures which use a
rarely changing set of keys.
However, I do not see any good alternative for PGP for personal
Hello everyone
As you probably know, Debian relies heavily on GnuPG for various
purposes, including:
- developer communication
- signing of tarballs and patches
- automated processes such as update validation by APT
The OpenPGP Working Group at IETF is currently working on a new
standard.
Also note that some of the listed packages are signed with 1024-bit DSA
(Logjam attack), which would be more concerning if there were no
additional release signatures.
Regards
Stephan
signature.asc
Description: This is a digitally signed message part
Hello Dimitri
On Fri, 2023-12-01 at 00:20 +, Dimitri John Ledkov wrote:
> This makes me wonder if signatures on uploaded or published .dsc have
> any value at all.
Cryptographically speaking, 160-bit hash algorithms are vulnerable to
collision attacks but not to preimage attacks. Even today,
In my opinion, this is yet another reason to use a proper cryptography
library (openssl, gnutls or gcrypt) instead of a custom implementation
for this kind of algorithm.
Over time, when these libraries add support for cryptography
acceleration instructions for more architectures, all programs
If you want to open that debate (again?), one should probably switch to
lzip. It uses the same LZMA compression like xz, but has a way more
sane file format.
Also note that the (pretended) multi-threading-capability of xz is
mostly based on its improper file format[1]:
> The xz-utils manual says
On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote:
> In the future the initramfs will (usually) be static as well.
Can you provide more information on that?
Thanks and regards
Stephan
signature.asc
Description: This is a digitally signed message part
On Fri, 2023-03-10 at 14:28 +, Jeremy Stanley wrote:
> Okay, so you're wanting to rely on encrypted /boot as an incomplete
> alternative to checking file signatures, because the current
> attestation solutions are also imperfect. Keep in mind that
> checksumming isn't providing protection from
Encryption per se does not protect against modification, I am aware of
that. That is even more true for disk encryption where the encrypted
data block has to fit into the physical disk block, so there is no room
for a MAC or signature. However, in combination with a filesystem like
btrfs which
Can you explain or refer to literature why encrypted /boot is
pointless?
Regards
PS: Let's for now ignore non-security benefits, e.g. that encrypted
/boot means that you do not have to decide on the size of your /boot
partition.
signature.asc
Description: This is a digitally signed message
That is also the main reason why I do not use automatic login. I need
to enter the password anyway.
Unfortunately, the same is true for smartcard login. An OpenPGP
smartcard would be perfect for both login (including SSH public key
auth) and unlocking the keyring, even better than a password, but
It is also not required to put an author name or any other information,
either. Copyright will still apply.
But it makes it really a lot easier for anyone who wants to re-use the
work or parts of it if they know who to contact. This matters even more
for computer programs than for fiction novels
Note that kernel.org signs the raw tar file and not the compressed
file. This way, they avoid issues like that and also allow conversion
into different compression formats while the signature stays valid.
Downside is that you have to decompress it first and then hash quite a
big file for
Since dark mode has become more common with GTK4 and Gnome, it would
also make sense to have day/night pairs of wallpapers etc.
Regards
Not a legal expert, but the "Finder" and "Safari" icons look
problematic to me.
Regards
The vmlinuz is usually small. The initrd can be quite big.
Regards
On Thu, 2022-10-06 at 11:48 +0200, Enrico Zini wrote:
> Device Start End Sectors Size Type
> /dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
> /dev/nvme0n1p2 1050624 1550335 499712 244M Linux filesystem
> /dev/nvme0n1p3 1550336 1000214527 998664192 476.2G
The Signal client for desktop is a really bad example of free software.
It does techically have a free license (or better say a jungle of
components with various free licenses), but it is almost impossible to
build it yourself. There is a reason why Debian does not have its own
builds.
Even the
IMHO, a (official) communcation channel for a project like Debian has
two requirements which are not met by Telegram:
1. Infrastructure should be controlled by the project.
2. Protocols should be standardized and universal. Ideally, users
should have free choice of their clients for various
As far as I understand it, the main point of BabaSSL is to add support
for Chinese developed ciphers and algorithms.
Long time ago in my student years, I was working with a German fork of
OpenSSL. The point was to add German elliptic curves (BSI and Deutsche
Telekom). They were eventually merged
Your text is quite chaotic, it is hard to distinguish the quotes from
your ideas what to do in Debian.
I think the main problem here are the programs which are presenting
source code to humans (text editors, terminals, HTML pages in Gitlab
etc.).
Quotes should always terminate everything. A
> i did the analysis (took 3 weeks)
Do you have a publication of that analysis? I was thinking the same
about the organization of Debian for some time but never did analysis
or compared it to other distros.
Also I like to add that reproducible builds are an excellent addition
to the mechanisms
Sorry, the follow-up mails loaded only after I wrote my response.
Regards
Stephan
Did you mean 2023?
Regards
Stephan
On Tue, 2021-12-07 at 23:35 +, Simon McVittie wrote:
> Flathub generally requires builds to be done on Flathub's
> infrastructure, from source code if possible, in the same way Debian
> generally requires builds to be done on buildds, from source if
> possible.
Are you sure about that? Is
Hello
My impression is that web based projects lean towards OpenSSL, while
for example the whole GTK/Gnome desktop stack is using GnuTLS (with
nettle/hogweed). So you will not get rid of either crypto stack.
Then I also think that OpenSSL 0.9.x/1.x and the new OpenSSL 3.x have
to be treated like
Possibly relevant:
- Are you using X11 or Wayland?
- Do you have proprietary graphics drivers installed?
- Does the freeze occur without those?
- Can you SSH into the machine after the screen/input freezes?
- Do you have other indications that the machine is still working?
Regards
On Sat, 2021-10-09 at 18:52 +0200, Jonas Smedegaard wrote:
> It is not source code.
>
> It is not binary code.
>
> It is not...
>
> The appropriate question is how it fits Debian Free Software
> Guidelines.
Programs with a license on the one hand which demands the right to
study and modify the
What about HTTP 304 Not Modified?
Regards
Nowadays you can also have BTRFS subvolumes, which does not require you
to define sizes in advance. In that case it is nice for snapshotting to
have separate subvolumes for things like home directories.
Regards
Thank you for the explanation. I think it covers most use cases.
However, it does not cover packages that do not actually install
programs but only perform changes to /etc or install something to /opt,
is that correct?
Regards
On Sun, 2021-07-18 at 11:13 +0200, Marco d'Itri wrote:
> I link /var/lib/dpkg/ to somewhere in /usr/, and I think that this is
>
What? No matter whether we merge “/bin” or not, “/usr” should stay
read-only.
Regards
On Thu, 2021-04-08 at 12:50 +0200, Dominik George wrote:
> (lutris ignores the Debian packages and installs copies of the games
> from who-knows-where).
How is that different from PIP, NPM, Ruby Gems, Rust Cargo etc., all in
main?
For non-developer use cases, I dislike these very much as well.
On Sun, 2021-04-04 at 11:30 +0200, Stephan Lachnit wrote:
> For winetricks it is a bit more tricky as it can download non-free
> dlls afaik.
How does this compare for instance to Firefox, which can/will download
non-free binaries for DRM?
Regards
The same applies to the GNOME/GTK stack, where Flatpak is the way to go
for active development. libgtk-3-dev is really only for building Debian
packages from their point of view, too.
But at least GNOME has scheduled releases which enable Debian stable to
maintain it, while npm, pip, gems, cargo
40 matches
Mail list logo
