The current upstream maintainer of python-chardet recently used the
Claude Code LLM to completely rewrite the library for version 7.0.0[1].
The source code now has no obvious direct relationship with previous
versions.
The maintainer used the LLM-based rewrite as justification to
unilaterally relicense the project from LGPL-2.1-or-later to MIT. This
has prompted a debate about whether or not the maintainer truly has the
right to do so, given their deep familiarity with the LGPL code and
other considerations. The original author of the library feels that the
relicensing was improper[2].
There is no great rush to make a decision about how to handle this
particular situation. I can keep python-chardet at 6.0.0 in Fedora for
quite a while. However, we in Fedora may end up having to make a
decision sooner or later on what to do about cases like this. Even if
the question can be somehow sidestepped for chardet, we can expect to be
faced with an increasing number of similar situations.
[1] https://github.com/chardet/chardet/pull/322
[2] https://github.com/chardet/chardet/issues/327
Hi all.
Please, help me to correctly recognize the license of XSD package [¹]
I have attached the files provided by source archive.
It looks like a "GPL-2.0-only WITH Universal-FOSS-exception-1.0"
[¹] https://src.fedoraproject.org/rpms/xsd
---
Antonio Trande
Fedora Project, User:Sagitter
Website: antoniotrande.blog
mailto: sagitter(a)fedoraproject.org
GPG key: 0x6ea362cc4c1aeac10b3a5c5402b0e70b4933065a
GPG keys server: https://pgp.mit.edu/
Given that this is related to legal stuff, I should preface this by
saying I am not a lawyer.
Recently, a new law was passed in California that requires OS vendors
to provide some limited info about a user's age via an API that
application distribution websites and application stores can use. [1]
Colorado seems to be working on a similar law. [2] The law will go into
effect January 1, 2027, it is no longer a draft. I do quite a bit of
work with an OS vendor (working with the Kicksecure [3] and Whonix [4]
projects), and we aren't particularly interested in blocking everyone
in California and Colorado from using our OSes, so we're currently
looking into how to implement an API that will comply with the laws
while also not being a privacy disaster. Given that other distributions
are also investigating what to do with this, and the law requires us to
make a "good faith effort to comply with [the] title, taking into
consideration available technology", I figured it would be a good idea
to bring the issue here.
At its core, the law seems to require that an "operating system"
(I'm guessing this would correspond to a Linux distribution, not an OS
kernel or userland) request the user's age or date of birth at "account
setup". The OS is also expected to allow users to set the user's age if
they didn't already provide it (because the OS was installed before the
law went into effect), and it needs to provide an API somewhere so that
app stores and application distribution websites can ask the OS "what
age bracket does this user fall into?" Four age brackets are defined,
"< 13", ">= 13 and < 16", ">= 16 and < 18", and ">= 18". It looks like
the API also needs to not provide more information than just the age
bracket data. A bunch of stuff is left unclear (how to handle servers
and other CLI-only installs, how to handle VMs, whether the law is even
applicable if the primary user is over 18 since the law ridiculously
defines a user as "a child" while also defining "a child" as anyone
under the age of 18, etc.), but that's what we're given to deal with.
The most intuitive place to put this functionality would be, IMO,
AccountsService. The main issue with that is that stable-release
distributions, and distributions based upon them, would be faced with
the issue of how to get an updated version of AccountsService integrated
into their software repositories, or how to backport the appropriate
code. The law goes into effect on January 1, 2027, Debian Bookworm is
going to be supported by ELTS until July 30, 2033, and we don't yet
know if Debian will care enough about California's laws to want to
backport a new feature in AccountsService into Debian Bookworm (or even
Trixie). Distributions based on Debian (such as Kicksecure and Whonix)
may still want to comply with the law though, so something using
AccountsService-specific APIs would be frustrating. Requiring a whole
separate daemon for the foreseeable future just for an age verification
API would also be annoying.
Another place the functionality could go is xdg-desktop-portal. This
one is a bit non-ideal for a couple of reasons; for one, the easiest
place to put the call would be in the Account portal, which returns
more information than the account's age bracket. This could potentially
be considered non-compliant with the law, as it states that the
operating system shall "[s]end only the minimum amount of information
necessary to comply with this title". This also comes with the
backporting disadvantages of an AccountsService-based implementation.
For this reason, I'd like to propose a "hybrid" approach; introduce a
new standard D-Bus interface, `org.freedesktop.AgeVerification1`, that
can be implemented by arbitrary applications as a distro sees fit.
AccountsService could implement this API so that newer versions
of distros will get the relevant features for free, while distros with
an AccountsService too old to contain the feature can implement it
themselves as a stop-gap solution.
Taking inspiration from the File Manager D-Bus interface [5], I think
something like the following might work:
<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node name="/org/freedesktop/AgeVerification1">
<interface name="org.freedesktop.AgeVerification1">
<method name="SetAge">
<arg type="s" name="User" direction="in"/>
<arg type="u" name="YearsOfAge" direction="in"/>
</method>
<method name="SetDateOfBirth">
<arg type="s" name="User" direction="in"/>
<arg type="s" name="Date" direction="in"/>
</method>
<method name='GetAgeBracket'>
<arg type="s" name="User" direction="in"/>
<arg type="u" name="AgeBracket" direction="out"/>
</method>
</interface>
</node>
* The 'User' argument would, in all instances, be expected to be the
UNIX account username of the user in question. This user account must
not be a system account (i.e. its UID must fall between UID_MIN and
UID_MAX as defined by /etc/login.defs). If a user is specified that
does not exist or whose UID is out of range, these methods will
return the error 'org.freedesktop.AgeVerification1.Error.NoSuchUser'.
If the specified user is not the same as the user making the method
call, and the user making the method call is not root, these methods
will return the error
'org.freedesktop.AgeVerification1.Error.PermissionDenied'.
* The 'YearsOfAge' argument of the 'SetAge' method should be an
unsigned integer specifying the age of the user in years at the time
of the method call. (The law specifically allows providing simply an
age value rather than a birth date if desired.)
* The 'Date' argument of the 'SetDateOfBirth' method should be a string
in ISO8601 format (i.e. YYYY-MM-DD) indicating the day on which the
user was born. If the argument is invalid, the method will return the
error 'org.freedesktop.AgeVerification1.Error.InvalidDate'.
* The 'AgeBracket' output argument of the 'GetAgeBracket' method will be
an unsigned integer between 1 and 4 inclusive, where 1 indicates that
the user is under 13 years old, 2 indicates that the user is at least
13 and under 16 years old, 3 indicates that the user is at least 16
and under 18 years old, and 4 indicates that the user is 18 years old
or older. If no age has been configured for the user yet, the method
will return the error
'org.freedesktop.AgeVerification1.Error.AgeUndefined'.
I propose that the exact way in which age information is stored by the
daemon should be left implementation-defined. For Kicksecure, the way
we implement it will almost certainly store only the age bracket and
require users to explicitly reconfigure their age once they are old
enough to move from one age bracket to another. Other implementations
may choose to store the date of birth or the age and date on which the
age was set so that they can automatically update the age bracket as
time passes. This interface will be provided *on the system bus* (NOT
the session bus!), and the D-Bus service that provides these services
should run as root. The file containing the user-to-age mappings should
be owned by root and should not be world-readable, to prevent leaking
the user's specific age to malicious applications.
Some things I did think about when writing the above but ultimately
decided to not propose:
* Detailed permission gating for the 'GetAgeBracket' method. The only
reason to do this would be for additional privacy, and
privacy-conscious users can simply lie about their age or the age of
the intended user. There isn't anything in the law (that I can tell)
that prevents the user from just saying "I'm 18" when the prompt
appears and going with it. This would also be really difficult to
implement outside of the context of xdg-desktop-portal, and would
probably only work with sandboxed apps if it was implemented that way.
* UX for actually requesting the age from the user. IMO this is out of
scope for FreeDesktop; individual distros should see to it that they
prompt for the user's age or birth date at "account setup" (whatever
that happens to be defined as for the distro in question), nudge the
user to provide the information later on for existing installations,
etc. Furthermore, this mechanism needs to work even on CLI-only
installs and maybe even on server installs, depending on how one
defines "general purpose computing device" (as specified by the law
in question), so defining any specific UX is likely infeasible. (If
this is required on servers, end-users will probably want to
auto-provision the age information somehow, and specifying how to do
that in a distribution-agnostic way is impossible given that Ubuntu
uses cloud-init, Fedora uses Kickstart and Ignition, etc.)
* Omitting the 'SetDateOfBirth' method. It can be lived without
legally, but without the method, it becomes difficult for software
that already records the user's date of birth to accurately implement
automatic age bracket adjustment as time passes. This isn't a feature
Kicksecure would use, but it's a feature some projects might be
interested in.
Thanks for taking a look at this.
--
Aaron
[1] https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=20252…
[2] https://leg.colorado.gov/bill_files/110990/download
[3] https://www.kicksecure.com/
[4] https://www.whonix.org/
[5] https://www.freedesktop.org/wiki/Specifications/file-manager-interface/
I'm going to hope that this is all satire.
-- Jamie
On 2026-03-17 14:00, Adenix NPSP wrote:
> Will there be a way for developers of "ageless" linux distros (linux
> distros without age verification) to handle such a plan while still being
> able to opt out of age verification?
>
> On Tue, Mar 17, 2026, 12:48 PM Marco Trevisan <marco.trevisan(a)canonical.com>
> wrote:
>
>> On decryption, I don't think we've to create another specific
>> implementation for this.
>>
>> What we all need (pretty desperately TBH, and for many things that
>> goes from authentication systems up to proper keyrings and password
>> managers) it's a proper secure enclave in the linux systems using
>> Virtualization-Based Security (VBS).
>>
>> There are already some implementations for the Linux kernel on which
>> both MS and Amazon are working, and I feel that we should ensure that
>> the ecosystem is ready for that.
>>
>> See:
>> https://www.iinuwa.xyz/blog/linux-passkeys-update/#hardening-platform-authe…
>>
>> Cheers
>>
>> Il giorno dom 8 mar 2026 alle ore 16:21 Personal (disroot.org) via
>> ubuntu-devel <ubuntu-devel(a)lists.ubuntu.com> ha scritto:
>>>
>>> 4 Mar 2026 05:12:31 FloofyWolf <debian-devel-list(a)floofywolf.net>:
>>>
>>>> Recently, a proposal has been made to implement an API for a new
>>>> California censorship regulation, “On the unfortunate need for an "age
>>>> verification" API for legal compliance reasons in some U.S. states” by
>>>> Aaron Rainbolt. I believe the approach outlined to be very
>>>> short-sighted, in that creating a bespoke API for each of the hundreds
>>>> of government censorship requirements that debian will presumably now
>>>> be following will result in much duplication of effort and an
>>>> unreliable user experience in which important censorship restrictions
>>>> may be missed and not implemented. As such, with people now supporting
>>>> the idea that debian should implement government censorship requests,
>>>> even creating new standards if needed, I propose the creation of a
>>>> censorship framework to speed implementation of current and future
>>>> censorship regulations.
>>>>
>>>> On installation, the user will be required to enter their location.
>>>> This information may be pre-filled if device location (GPS) or other
>>>> sources of location data (IP geolocation, selected timezone, etc) are
>>>> available. If the user enters a location that does not match any
>>>> gathered location data, this will be immediately stored and sent to
>>>> authorities in both the detected location and the entered location to
>>>> alert them of a citizen potentially trying to evade censorship
>>>> regulations. If the location entered requires further information,
>>>> such as whether an encryption license has been acquired, the user’s
>>>> age, etc, it will be requested at this point. This process will also
>>>> be repeated every time a user account is created, and will require
>>>> implementation in both graphic and text-based account management
>>>> utilities, such as adduser.
>>>>
>>>> This location and user data will be managed by a new daemon,
>>>> systemd-censord, and stored in an encrypted form and otherwise
>>>> protected so as not to be readable or modifiable by any user on the
>>>> system. To ensure privacy, great care must be taken to prevent a user
>>>> from being able to access other users’ personal information, and to
>>>> ensure compliance with censorship regulations, no user may be able to
>>>> change their location in any fashion which bypasses dedicated
>>>> utilities, which will perform the required location validation and
>>>> discrepancy authority notice functions when the user requests to change
>>>> their location, such as for moving house or travel.
>>>>
>>>> Systemd units will be created for every desired censorship function,
>>>> and will be started based on the user’s location. For example, a unit
>>>> for Kazakhstan will implement the government-required backdoor, a unit
>>>> for China will implement keyword scans and web access blocks (more on
>>>> this later), a unit for Florida will ban all packages with “trans” in
>>>> the name (201 packages in current stable distribution), a unit for
>>>> Oklahoma will ensure all educational software is compliant with the
>>>> Christian Holy Bible, a unit for the entire United States will prevent
>>>> installation of any program capable of decoding DVD or BluRay media,
>>>> and a unit for California will provide the user’s age to all
>>>> applications and all web sites from which applications may be
>>>> downloaded. As can be seen, multiple units may be started for a given
>>>> location.
>>>>
>>>> All communication will be over D-Bus, with each application proactively
>>>> asking systemd-censord for permission to perform any operations which
>>>> may foreseeably be restricted anywhere in the world. A standardized
>>>> list of permissions will need to be developed, as well as standard
>>>> personal data fields, such as user age. Blobs for the storage of media
>>>> player keys and digital rights management content could also be added
>>>> as additional functionality.
>>>>
>>>> Since keyword scanning and web filtering are extremely common
>>>> government interests, a dedicated daemon for this function should be
>>>> created, with kernel hooks to allow inspection of all internal program
>>>> structures as well as internet traffic. This daemon can then be
>>>> started with different filter configuration files for each systemd unit
>>>> triggered by the user’s location. To comply with book bans common in
>>>> many US states, such as those restricting access to books on
>>>> LGBTQ[[:alnum:]]* topics or having non-white characters, this module
>>>> should also automatically search the filesystem for prohibited ebook
>>>> files.
>>>>
>>>> Many packages will need to be altered to include specific functionality
>>>> relevant to censorship, including dpkg. For example, installing tor
>>>> will be prohibited in many countries, and some packages, like
>>>> fortunes-off, will be restricted based on the user’s age, as will most
>>>> games. Web browsers will have to be patched to send the user’s age to
>>>> all websites hosting applications for download. Encryption packages
>>>> will have to check if a systemd unit limiting encryption strength is
>>>> running, and set their maximum key length, disable features, or send
>>>> private keys to a specified IP address determined by the unit.
>>>>
>>>> To prevent users from bypassing censorship requirements, debian will
>>>> need to switch to being a binary-only distribution with signed
>>>> binaries, signed kernel, and signed kernel modules, with mandatory
>>>> secureboot, and controls to prevent any non-signed software from being
>>>> installed, written, or compiled, as any foreign sources of software may
>>>> fail to query systemd-censord or may fail to respect the permissions it
>>>> returns.
>>>>
>>>> On the non-software side, the debian licenses will need to be modified
>>>> to disallow removal or alteration of any of these features by
>>>> derivative distributions – for example, no distribution will be allowed
>>>> to ship without systemd because then systemd-censord may not work
>>>> correctly. In addition, the licenses for all packaged software will
>>>> need to be amended to disallow removal of censorship functionality.
>>>>
>>>> As I’m sure is obvious, if debian is going to comply with government
>>>> censorship regulations, a universal framework allowing easy addition of
>>>> new rules will greatly reduce developer time over individual ad-hoc
>>>> implementations of each new freedom restriction. Complying with only
>>>> one regulation, such as California’s attempts to prevent minors from
>>>> accessing unapproved information, makes no sense when there’s hundreds
>>>> or thousands of other regulations not currently being complied with.
>>>> This framework should ensure all users get to experience their full
>>>> censorship regime no matter where they are in the world.
>>>>
>>>> Thanks for reading, and I hope we can work together to help Linux
>>>> implement as much censorship as possible!
>>>> --Floofy Wolf
>>>
>>> Nice work!
>>>
>>> I would agree with encrypting systemd-censord, but *how* to decrypt it, I
>>> have an idea for. It requires /etc/machine-id, AppArmor or SELinux, FDE,
>>> and a new *specially* compiled kernel module. Feel free to critique it
>>> and give me new ideas.
>>>
>>> Starting off, /etc/machine-id is generated upon new installations with
>>> systemd-firstboot, and it is unique to all systems. This means it can be
>>> used as a shared key along with a unique salt to prevent rainbow table
>>> attacks. This would be pretty bad for anyone to see publicly, so now we
>>> have to come up with a solution.
>>>
>>> My solution to this is FDE with TPM2, a kernel module, and an MAC.
>>> Firstly, all systems must have FDE with TPM2 from hereon. Any system that
>>> hasn't had it before is now an unsupported configuration. Secondly, the
>>> new kernel module is included in the initramfs so that it can start
>>> reading /etc/machine-id after root is mounted, but before any MAC can do
>>> anything to prevent it from being seen. Finally, the kernel module
>>> decrypts systemd-censord using the machine-id and salt, runs it, and
>>> encrypts it again. For good measure, AppArmor or SELinux would hide
>>> systemd-censord and the kernel modules.
>>>
>>> This is not fully concrete, but I believe this is a starting point. I am
>>> fully open to other ideas.
>>>
>>> Cheers,
>>>
>>> --
>>> Artur Manuel
>>> amadaluzia
>>>
>>> --
>>> ubuntu-devel mailing list
>>> ubuntu-devel(a)lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>>
>>
>
--
Jamie Null (They/Them)
E: Lav(a)lavender.earth
Attn: Key EC31 8C72 C7CB 900E A0FC is revoked as of 2026-01-29T08:30Z.
"A person cannot be made to suffer a grossly disproportionate punishment
simply to send a message to discourage others from offending." — R v.
Nur, 2015 SCC 15, [2015] 1 S.C.R. 773, per McLachlin CJ, at para 45
Hi, I sent initially to legal(a)fedoraproject.org but then I saw this list so perhaps it was the wrong address.
My daughter is 13 years old, based in Italy, and would like to collaborate with Fedora Design team on the wallpapers design.
She is already 13 so she should be fine according to https://docs.fedoraproject.org/en-US/legal/privacy/#_our_commitment_to_chil…
But when she tried to register for her Fedora account, the system is asking to confirm she's at least 16yo.
There's no indication that the checkbox is going to have legal implications and the hint there is that you must check the box if you want to continue.
The temptation to just check the box and go ahead without asking has been pretty high but then she stopped and asked me.
Is there a way for me as her parent to approve the creation of a Fedora account allowing her to contribute directly?
I can proxy her contributions and give her credit on the submissions but will be more motivating for her being recognized directly for her work.
Thanks,
Hi all.
Checking the license of next psblas3 release, `licensecheck` tool recognizes this license file [1] as CMU
Upstream confirmed that psblas3 is distributed under a BSD-3-Clause instead [2].
Why does it look like `licensecheck` is confused with this license?
[1] https://github.com/sfilippone/psblas3/blob/development/LICENSE
[2] https://github.com/sfilippone/psblas3/issues/37
---
Antonio Trande
Fedora Project, User:Sagitter
Website: antoniotrande.blog
mailto: sagitter(a)fedoraproject.org
GPG key: 0x6ea362cc4c1aeac10b3a5c5402b0e70b4933065a
GPG keys server: https://pgp.mit.edu/
On Mon, 09 Mar 2026 19:39:52 -0600
"Jeremy Soller" <jeremy(a)system76.com> wrote:
> Hello everyone,
>
> My name is Jeremy Soller, and I am Principal Engineer at System76. We
> released a statement on Age Verification laws last Thursday that you
> can read here:
>
> https://blog.system76.com/post/system76-on-age-verification
>
> Our Founder and CEO, Carl Richell, was able to get a meeting with
> Senator Matt Ball today to discuss the Colorado version of the
> California bill, SB26-051. His statements after the meeting are as
> follows:
>
> https://floss.social/@carlrichell@fosstodon.org/116201429734101067
Wow, this is great to see! Thank you (both you and Carl) for doing
this, and for letting us know!
--
Aaron
> > Today, I met with Colorado Senator Matt Ball, co-author of Colorado
> > OS Age Attestation Bill SB26-051.
> >
> > Sen. Ball suggested excluding open source software from the bill.
> > This appears to be a real possibility.
> >
> > Amendments are expected for the CA age attestation bill. It's my
> > hope we can move fast enough to influence excluding open source in
> > the CA bill amendments.
> >
> > No illusions, it's an uphill battle, but we have an open door to
> > advocate for the open source community.
>
> At this time, we are seeing what kinds of changes might be made to
> these laws before they become effective. I would not generally advise
> working on any technical solution when the laws are ambiguous and
> likely to be amended. In the best case, although I believe it is
> unlikely, open-source operating systems would not have any work to do
> at all. In the worst case, different jurisdictions may have
> conflicting laws.
>
> We and our users greatly value our privacy, and I would hope not to
> see over-eager work on a technical implementation that is heavy
> handed and potentially jurisdiction specific. We at System76 are also
> awaiting the legal opinions of other operating systems, like Ubuntu,
> and those would likely be valuable to all potentially affected
> operating systems.
>
> Thank you,
>
Submitting smallstep ACME CA, a go project,
https://bugzilla.redhat.com/show_bug.cgi?id=2418762
I ran into a license problem/question.
A dependency is https://github.com/google/go-tpm-tools
This module concatenates several submodule licenses into
a single LICENSE file:
https://github.com/google/go-tpm-tools/blob/main/LICENSE
There is a divider, and it includes the LICENSE for a submodule,
simulator/ms-tpm-20-ref
I have two questions at the end. Here is the background.
This submodule is NOT included in the vendored code for the Fedora
package. But naturally, askalono objects to the concatenated license
file. I split the LICENSE file up into the parts marked by dividers. The
license it labels proprietary is the Trusted Computing Group
License. It seems innocuous to me, but IANAL. The Microsoft BSD license
says "no patent licenses are granted", but askalono doesn't object.
It gets more complicated. There are several dividers. The first divider
says
--------
Microsoft simulator code (in simulator/ms-tpm-20-ref) uses the following
licenses:
--------
To me, this says ALL the following licenses are for
simulator/ms-tpm-20-ref - and since that submodule is not included, we
should be legally able to ignore them. However the plain English reading
doesn't always apply with lawyers. Later on, another divider says
--------
A portion of the source code is derived from the TPM specification,
which has a TCG copyright. It is reproduced here for reference.
--------
So, MAYBE "the source code" refers to ms-tpm-20-ref, or MAYBE to the
go-tpm-tools module as a whole. It depends on whether the divider
grammar is left associative or right associative.
Questions:
1. Is the TCGL possibly an ok license that could be approved, and thus
make the next question moot?
2. If lawyers agree that TCGL applies to the ms-tpm-20-ref submodule
(which is NOT included in the vendored source or package), then what
is the best way to allow this and document why? Modifying the upstream
LICENSE is frowned upon.
On Tue, 3 Mar 2026 15:56:03 +0100
Aigars Mahinovs <aigarius(a)gmail.com> wrote:
> There is more. A casual look around the legal landscape also uncovers
> this law in Brazil:
> https://www.planalto.gov.br/ccivil_03/_ato2023-2026/2025/Lei/L15211.htm
> and France also has some related laws:
> https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000045287677
>
> IANAL, but IMHO the requirements from Debian/Ubuntu side *could* be
> fulfilled if there is a package implementing the requested
> functionality (setting of age/birth year for specific accounts and
> then communicating relevant age brackets to the app requesting that).
> That package would be "part of" the operating system, even if the
> installer chooses not to download full installation images or chooses
> not to install ALL available Debian packages. As long as the
> installation and configuration is easy enough to do for a concerned
> parent from packages *in the main package archive*, then it could be
> argued that compliance is provided. In the end it is up to the
> admin/installer of the device to configure it correctly for the
> users. This also solves the privacy concerns as the admin of the
> system opts in to using these restrictions explicitly when adding age
> setting to the new user accounts. Also privacy laws typically are
> expected to step aside to the explicit requirements of other laws to
> function. So if a child protection law says that the age bracket of
> the child *must* be provided/transmitted, then privacy law can not
> forbid doing so (unless stated in that law explicitly).
>
> Naturally this API needs to be agreed on on a cross-distribution
> layer, for example in the Freedesktop.org context.
>
> However, these questions are IMHO more important in contexts where
> there is already a large exposure to system users in the affected age
> brackets and also in the affected jurisdictions. And that is why I
> added the Debian-Edu mailing list to the CC here. A typical
> school-wide Debian Edu installation would have thousands of accounts
> for individual children attending the school, they'd be in different
> age brackets and they'd graduate from one bracket to the next really
> often. Too often for manual actions at those stages to be viable.
> Additionally, if there is an actual policy attention to Debian
> installation in the context of such laws, then installations in
> schools are likely to be among the first to be looked at.
>
> With the above in mind, thinking technically, IMHO the correct way
> would be to have a field for date of birth for user accounts
> (potentially shortened down to MM-YYYY or YYYY) and an API that (on
> request) reads that value, reads the pre-configured jurisdiction (or
> jurisdiction configuration) and returns the age bracket value. Keep
> in mind that this date of birth information may already be coming
> into the system from LDAP, MS Active Directory or similar external
> account management systems. It *might* be acceptable to have the API
> only work if users are authenticated via a supported account
> management system with a defined dateOfBirth attribute, but then
> distributions should really provide an easy way for a parent to be
> able to set up and maintain such a system locally.
I think the idea you're thinking of may make sense for Debian, however
I would like to reinforce that for Whonix in particular, storing an
exact birth date anywhere on the system (encrypted or otherwise, locked
to the root account or not) is unacceptable because of its potential
use in fingerprinting the user of an infected system. Our goals and an
educational institution's goals in this regard are going to be
diametrically opposed, so there is no way to work at this "depth" and
come up with a solution that works for everyone.
That isn't to say your idea is bad at all; it's a great idea for one
implementation of an eventual specification. The specification simply
needs to leave room for implementations that do the exact opposite.
That's why I was using org.freedesktop.FileManager1 as a sort of "base"
- the spec for it defines an API that anyone can implement, and
implementations can (and in practice do) provide services via that spec
that behave in all manner of different ways under the hood, some of
which result in different user-facing behavior. That's the kind of spec
I think will work best here, since it means schools can have an age
tracking system that allows for automatic age bracket updates and
harvesting of information from existing sources, and Whonix can save
the age bracket somewhere and then never touch it again unless the user
chooses to update it.
--
Aaron
> So a question to Debian EDU developers - are you aware of the
> age-reporting laws and maybe of the work already in progress to
> address the concerns these laws raise?
>
>
> On Sun, 1 Mar 2026 at 20:48, Aaron Rainbolt <arraybolt3(a)gmail.com>
> wrote:
>
> > Given that this is related to legal stuff, I should preface this by
> > saying I am not a lawyer.
> >
> > Recently, a new law was passed in California that requires OS
> > vendors to provide some limited info about a user's age via an API
> > that application distribution websites and application stores can
> > use. [1] Colorado seems to be working on a similar law. [2] The law
> > will go into effect January 1, 2027, it is no longer a draft. I do
> > quite a bit of work with an OS vendor (working with the Kicksecure
> > [3] and Whonix [4] projects), and we aren't particularly interested
> > in blocking everyone in California and Colorado from using our
> > OSes, so we're currently looking into how to implement an API that
> > will comply with the laws while also not being a privacy disaster.
> > Given that other distributions are also investigating what to do
> > with this, and the law requires us to make a "good faith effort to
> > comply with [the] title, taking into consideration available
> > technology", I figured it would be a good idea to bring the issue
> > here.
> >
> > At its core, the law seems to require that an "operating system"
> > (I'm guessing this would correspond to a Linux distribution, not an
> > OS kernel or userland) request the user's age or date of birth at
> > "account setup". The OS is also expected to allow users to set the
> > user's age if they didn't already provide it (because the OS was
> > installed before the law went into effect), and it needs to provide
> > an API somewhere so that app stores and application distribution
> > websites can ask the OS "what age bracket does this user fall
> > into?" Four age brackets are defined, "< 13", ">= 13 and < 16", ">=
> > 16 and < 18", and ">= 18". It looks like the API also needs to not
> > provide more information than just the age bracket data. A bunch of
> > stuff is left unclear (how to handle servers and other CLI-only
> > installs, how to handle VMs, whether the law is even applicable if
> > the primary user is over 18 since the law ridiculously defines a
> > user as "a child" while also defining "a child" as anyone under the
> > age of 18, etc.), but that's what we're given to deal with.
> >
> > The most intuitive place to put this functionality would be, IMO,
> > AccountsService. The main issue with that is that stable-release
> > distributions, and distributions based upon them, would be faced
> > with the issue of how to get an updated version of AccountsService
> > integrated into their software repositories, or how to backport the
> > appropriate code. The law goes into effect on January 1, 2027,
> > Debian Bookworm is going to be supported by ELTS until July 30,
> > 2033, and we don't yet know if Debian will care enough about
> > California's laws to want to backport a new feature in
> > AccountsService into Debian Bookworm (or even Trixie).
> > Distributions based on Debian (such as Kicksecure and Whonix) may
> > still want to comply with the law though, so something using
> > AccountsService-specific APIs would be frustrating. Requiring a
> > whole separate daemon for the foreseeable future just for an age
> > verification API would also be annoying.
> >
> > Another place the functionality could go is xdg-desktop-portal. This
> > one is a bit non-ideal for a couple of reasons; for one, the easiest
> > place to put the call would be in the Account portal, which returns
> > more information than the account's age bracket. This could
> > potentially be considered non-compliant with the law, as it states
> > that the operating system shall "[s]end only the minimum amount of
> > information necessary to comply with this title". This also comes
> > with the backporting disadvantages of an AccountsService-based
> > implementation.
> >
> > For this reason, I'd like to propose a "hybrid" approach; introduce
> > a new standard D-Bus interface, `org.freedesktop.AgeVerification1`,
> > that can be implemented by arbitrary applications as a distro sees
> > fit. AccountsService could implement this API so that newer versions
> > of distros will get the relevant features for free, while distros
> > with an AccountsService too old to contain the feature can
> > implement it themselves as a stop-gap solution.
> >
> > Taking inspiration from the File Manager D-Bus interface [5], I
> > think something like the following might work:
> >
> > <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object
> > Introspection 1.0//EN"
> > "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
> > <node name="/org/freedesktop/AgeVerification1">
> > <interface name="org.freedesktop.AgeVerification1">
> > <method name="SetAge">
> > <arg type="s" name="User" direction="in"/>
> > <arg type="u" name="YearsOfAge" direction="in"/>
> > </method>
> > <method name="SetDateOfBirth">
> > <arg type="s" name="User" direction="in"/>
> > <arg type="s" name="Date" direction="in"/>
> > </method>
> > <method name='GetAgeBracket'>
> > <arg type="s" name="User" direction="in"/>
> > <arg type="u" name="AgeBracket" direction="out"/>
> > </method>
> > </interface>
> > </node>
> >
> > * The 'User' argument would, in all instances, be expected to be the
> > UNIX account username of the user in question. This user account
> > must not be a system account (i.e. its UID must fall between
> > UID_MIN and UID_MAX as defined by /etc/login.defs). If a user is
> > specified that does not exist or whose UID is out of range, these
> > methods will return the error
> > 'org.freedesktop.AgeVerification1.Error.NoSuchUser'. If the
> > specified user is not the same as the user making the method call,
> > and the user making the method call is not root, these methods will
> > return the error
> > 'org.freedesktop.AgeVerification1.Error.PermissionDenied'.
> > * The 'YearsOfAge' argument of the 'SetAge' method should be an
> > unsigned integer specifying the age of the user in years at the
> > time of the method call. (The law specifically allows providing
> > simply an age value rather than a birth date if desired.)
> > * The 'Date' argument of the 'SetDateOfBirth' method should be a
> > string in ISO8601 format (i.e. YYYY-MM-DD) indicating the day on
> > which the user was born. If the argument is invalid, the method
> > will return the error
> > 'org.freedesktop.AgeVerification1.Error.InvalidDate'.
> > * The 'AgeBracket' output argument of the 'GetAgeBracket' method
> > will be an unsigned integer between 1 and 4 inclusive, where 1
> > indicates that the user is under 13 years old, 2 indicates that the
> > user is at least 13 and under 16 years old, 3 indicates that the
> > user is at least 16 and under 18 years old, and 4 indicates that
> > the user is 18 years old or older. If no age has been configured
> > for the user yet, the method will return the error
> > 'org.freedesktop.AgeVerification1.Error.AgeUndefined'.
> >
> > I propose that the exact way in which age information is stored by
> > the daemon should be left implementation-defined. For Kicksecure,
> > the way we implement it will almost certainly store only the age
> > bracket and require users to explicitly reconfigure their age once
> > they are old enough to move from one age bracket to another. Other
> > implementations may choose to store the date of birth or the age
> > and date on which the age was set so that they can automatically
> > update the age bracket as time passes. This interface will be
> > provided *on the system bus* (NOT the session bus!), and the D-Bus
> > service that provides these services should run as root. The file
> > containing the user-to-age mappings should be owned by root and
> > should not be world-readable, to prevent leaking the user's
> > specific age to malicious applications.
> >
> > Some things I did think about when writing the above but ultimately
> > decided to not propose:
> >
> > * Detailed permission gating for the 'GetAgeBracket' method. The
> > only reason to do this would be for additional privacy, and
> > privacy-conscious users can simply lie about their age or the age
> > of the intended user. There isn't anything in the law (that I can
> > tell) that prevents the user from just saying "I'm 18" when the
> > prompt appears and going with it. This would also be really
> > difficult to implement outside of the context of
> > xdg-desktop-portal, and would probably only work with sandboxed
> > apps if it was implemented that way.
> > * UX for actually requesting the age from the user. IMO this is out
> > of scope for FreeDesktop; individual distros should see to it that
> > they prompt for the user's age or birth date at "account setup"
> > (whatever that happens to be defined as for the distro in
> > question), nudge the user to provide the information later on for
> > existing installations, etc. Furthermore, this mechanism needs to
> > work even on CLI-only installs and maybe even on server installs,
> > depending on how one defines "general purpose computing device" (as
> > specified by the law in question), so defining any specific UX is
> > likely infeasible. (If this is required on servers, end-users will
> > probably want to auto-provision the age information somehow, and
> > specifying how to do that in a distribution-agnostic way is
> > impossible given that Ubuntu uses cloud-init, Fedora uses Kickstart
> > and Ignition, etc.)
> > * Omitting the 'SetDateOfBirth' method. It can be lived without
> > legally, but without the method, it becomes difficult for software
> > that already records the user's date of birth to accurately
> > implement automatic age bracket adjustment as time passes. This
> > isn't a feature Kicksecure would use, but it's a feature some
> > projects might be interested in.
> >
> > Thanks for taking a look at this.
> >
> > --
> > Aaron
> >
> > [1]
> > https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=20252…
> > [2] https://leg.colorado.gov/bill_files/110990/download
> > [3] https://www.kicksecure.com/
> > [4] https://www.whonix.org/
> > [5]
> > https://www.freedesktop.org/wiki/Specifications/file-manager-interface/
> > --
> > ubuntu-devel mailing list
> > ubuntu-devel(a)lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
> >
>
>