> Is the change technical or legal/philosophical? You could call this
> a Turing test for copyright.
This is not a new issue at all. I remember that back in the day in
order to legally reverse engineer a computer program, companies had to
set up two separate teams of developers.
One team reads the
GnuPG 2.4 has landed in Sid.
I am already happily using GnuPG with TPM support (from experimental)
for several months now without problems, including for signing
automated backups with a machine-bound key. This will probably be
available for everyone in Trixie.
Thanks to everyone involved for ma
> sorry but I am confused... can you explain at a beginner level what
> is the difference between a certificate and a "key" in the sense it
> is used in the Developers Reference?
A certificate is a key with a name attached to it. So in the case of
Debian developer's PGP keys, it means the same thin
Am Samstag, dem 15.03.2025 um 07:47 -0700 schrieb Soren Stoutner:
> It’s important enough to me.
Not important enough to fix your formatting and encoding, it appears.
Regards
signature.asc
Description: This is a digitally signed message part
Am Donnerstag, dem 13.03.2025 um 02:37 +0100 schrieb Dirk Lehmann:
> GPU shaders should be clearly respected as software (and not
> hardware). Therefore, `intel-media-va-driver-non-free` is rightly in
> the Debian archive `non-free`.
First of all, I completely agree that:
1. shaders are computer
Am Montag, dem 03.03.2025 um 14:42 -0700 schrieb Soren Stoutner:
> Interesting. I guess that text could be interpreted as “Do not send
> an HTML part, even if you also send a plain text part.”
Are you serious? That does not make any sense.
> Please don't send your messages in HTML; use plain tex
Hello everyone
The “drivers” for hardware video decoders on Intel GPUs have been split
into free and non-free packages.
https://packages.debian.org/en/sid/intel-media-va-driver
https://packages.debian.org/en/sid/intel-media-va-driver-non-free
The difference between the two is that the Intel sour
Am Montag, dem 10.03.2025 um 13:27 +0530 schrieb Pirate Praveen:
> Basically hardware manufacturers are withholding code that they could
> give you easily
It is often not that easy because of stupid laws, for example laws that
require vendors of radio devices to restrict the frequency range. That
i
Am Sonntag, dem 09.03.2025 um 22:13 +0100 schrieb Philip Hands:
> Stephan Verbücheln (against? at least against mixed HTML)
- against mixed HTML
- against unwrapped lines without a defined method/encoding
- okay with format=flowed
Disclaimer: Not a Debian developer.
Regards
signature.
Am Samstag, dem 08.03.2025 um 14:51 +0100 schrieb Johannes Schauer
Marin Rodrigues:
> If you don't trust the vendor, then it makes no difference whether or
> not new official firmware/microcode can be uploaded/flashed or not.
> If you don't trust the vendor, then the initial microcode that came
> w
The ideal laptop in my dreams is running pure Debian on a RISC-V CPU,
and all firmware from BIOS/EFI to peripheral devices has the source
code available with a license which allows the free-software community
to maintain it and remove undesired features.
Unfortunately, even though we are getting c
Am Freitag, dem 07.03.2025 um 23:05 +0530 schrieb pan...@disroot.org:
> I acknowledge that some users—myself included—may need to install
> non-free firmware for WiFi, Bluetooth, or graphics driver
> I understand that users need proprietary drivers to run certain
> hardware, and Debian should not
Am Mittwoch, dem 05.03.2025 um 14:38 + schrieb Jeremy Stanley:
> There's also a several-month freeze after taking a snapshot of
> packages from sid before the release occurs, so when an Ubuntu LTS
> release happens the contemporary age of packages in the prior LTS is
> well over two years by
Am Mittwoch, dem 05.03.2025 um 09:14 +0100 schrieb Gard Spreemann:
> I do need to point out that the current cycle has been approximately
> 2 years long for quite a while, not 5.
That is technically correct, but the freeze period is quite long as
well. As a result, the software is significantly ol
In my opinion, the better solution would be to have more backports in
the stable release because people are mostly unhappy with outdated apps
and not with outdated essential core components.
This would probably not even require a policy change in Debian. But it
requires a lot of people with a lot
> However, I would appreciate it if this discussion were not hijacked
> to discuss HTML vs. plain text.
In case we define any new rules, it has to cover both.
> That is interesting. I have Kmail set to wrap at 80 columns.
> However, it wouldn’t surprise me if Kmail has some bug in this
> regard
Am Montag, dem 03.03.2025 um 13:38 -0700 schrieb Soren Stoutner:
> Also, as I mentioned elsewhere in this thread, this is not a
> discussion about the merits of HTML vs plain text. As long as emails
> to the mailing list contain a plain text part, I know of no problem
> caused by them also contain
Are you aware that you are sending HTML messages the whole time?
Are you aware that in those HTML parts, the source code is limited to
80 characters per line?
Have you ever noticed that this is also the case for base64-encoded
binary attachments?
Are you aware that even the text/plain section of
Wrapping at 72 is intentional to allow a few levels of quotations. That
is where the slightly different numbers come from. The hard limit is 80
because of the 80x24 terminal convention.
Regards
signature.asc
Description: This is a digitally signed message part
On Wed, 2025-02-26 at 10:27 -0500, Jeremy Bícha wrote:
> No. We are not going to build GNOME for Trixie without support for
> Xorg.
My question was neither of that.
1. Gnome can already be installed without Xorg in Bookworm and works
fine.
2. I was talking about removing specifically Xwayland (not
According to reports and changelogs, Gnome 48 should be working without
Xwayland.
https://gitlab.gnome.org/GNOME/gdm/-/blob/main/NEWS
Can you remove the package dependency in Debian?
Regards
signature.asc
Description: This is a digitally signed message part
> Thank you. I am unable to duplicate these issues with the information
> provided. Please report these as Debian bugs instead of on this
> mailing list.
I am planning to do more systematic and reproducible tests on a
dedicated system. I can file Debian bug reports if necessary, after
checking wit
On Thu, 2025-02-06 at 14:48 -0500, Jeremy Bícha wrote:
> Please be specific about the breakage you are seeing. The best way to
> do this is to file bugs against affected packages instead of emailing
> this list.
It was not distribution-level breakage but upstream bugs. I immediately
observed multi
Sid is flooded with early beta versions of many Gnome components. This
is causing a lot of breakage. Are they not supposed to go to
experimental?
Regards
Stephan
Incomplete list of affected packages:
epiphany-browser/unstable 48~beta-1
epiphany-browser-data/unstable 48~beta-1
gnome-backgrounds
This appears silly from an engineering perspective, but there is a
specific motivation behind it: Proton (the mail company) wants this to
simplify the implementation of PGP with Browser APIs.
As you said, too many optional ciphers are bad for compatibility. Note
that the key preferences do not hel
One of the prominently announced features of the 2.3/2.4 branches was
multi-smartcard support and support for TPM 2.0 key wrapping.
Regards
signature.asc
Description: This is a digitally signed message part
Since GnuPG 2.4 probably does not have any features removed (compared
to 2.2), is there anything other to do than patching the defaults for
new keys?
Debian has patches regarding GnuPG key defaults anyway, e.g. RSA key
size of 3072.
Regards
signature.asc
Description: This is a digitally signed
GnuPG 2.4 was released in 2022, long before the LibrePGP schism. It is
generally not clear to me how the divergence from upstream is a reason
to favor 2.2 over 2.4, except that patches have to be ported (once?).
I also do not understand what is wrong/lacking with the already patched
versions in Ex
Current Ubuntu 24.04 LTS also uses GnuPG 2.4 and probably has a similar
set of patches.
Regards
signature.asc
Description: This is a digitally signed message part
Please note that GnuPG 2.2 is also end of life now.
https://gnupg.org/download/index.html
Regards
signature.asc
Description: This is a digitally signed message part
On Thu, 2024-12-05 at 13:28 -0500, Theodore Ts'o wrote:
> Well, it seems most of the people who are complaining about the
> dependency (Depends / Recommends / Suggests) inflation are primarily
> complaining about the disk space thatis involved.
Localization is not only about disk space, but also m
I tried to find a blocking bug before my question on debian-devel, but
I could not find any bug which justifies the delay.
Note that Ubuntu 24.04 LTS also already uses GnuPG 2.4.x, so I do not
expect a problem with the Debian tooling base like dpkg and apt.
Regards
signature.asc
Description: Th
Hello everyone
Debian Trixie and Sid still have GnuPG 2.2.x. GnuPG 2.4.5 is available
in Experimental.
GnuPG 2.4.0 was released on December 20, 2022. The 2.4.x series has
various useful new features such as TPM support.
Is it realistic to get GnuPG 2.4 into Trixie before the freeze?
What is mis
The original e-mail appears to be this one:
https://lists.debian.org/debian-devel/2022/03/msg00251.html
It has not been modified. Note that it has an inline and an attached
signature. (Both cannot be validated because HTML has broken the
signature.)
Regards
signature.asc
Description: This is a
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 t
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 distinc
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 ob
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
Debi
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 all
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
s
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.
https:
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 will
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 chec
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 part
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 o
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 validatio
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 Fl
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 platfo
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 i
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 contro
> 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 yo
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 there
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. But
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 e
74 matches
Mail list logo
