* kanidm cli logs on debug level - Fixes#2745
* such clippy like wow
* It's important for a wordsmith to know when to get its fixes in.
* updootin' wasms
Use fully qualified container URLS instead of abbrevations to make the
quickstart guide better approachable for non-docker container engines,
which might not default to using docker.io.
Signed-off-by: phoenix <felix.niederwanger@suse.com>
This completely reworks how we approach and handle cryptographic keys in Kanidm. This is needed as a foundation for replication coordination which will require handling and rotation of cryptographic keys in automated ways.
This change influences many other parts of the code base in it's implementation.
The primary influences are:
* Modification of how domain user signing keys are revoked or rotated.
* Merging of all existing service-account token keys are retired (retained) keys into the domain to simplify token signing and validation
* Allowing multiple configurations of local command line tools to swap between instances using disparate signing keys.
* Modification of key retrieval to be key id based (KID), removing the need to embed the JWK into tokens
A side effect of this change is that most user authentication sessions and oauth2 sessions will have to be re-established after upgrade. However we feel that session renewal after upgrade is an expected side effect of an upgrade.
In the future this lays the ground work to remove a large number of legacy key handling processes that have evolved, which will allow large parts of code to be removed.
Fixes#2601Fixes#393 - gid numbers can be part of the systemd nspawn range.
Previously we allocated gid numbers based on the fact that uid_t is a u32, so we allowed 65536 through u32::max. However, there are two major issues with this that I didn't realise. The first is that anything greater than i32::max (2147483648) can confuse the linux kernel.
The second is that systemd allocates 524288 through 1879048191 to itself for nspawn.
This leaves with with only a few usable ranges.
1000 through 60000
60578 through 61183
65520 through 65533
65536 through 524287
1879048192 through 2147483647
The last range being the largest is the natural and obvious area we should allocate from. This happens to nicely fall in the pattern of 0x7000_0000 through 0x7fff_ffff which allows us to take the last 24 bits of the uuid then applying a bit mask we can ensure that we end up in this range.
There are now two major issues.
We have now changed our validation code to enforce a tighter range, but we may have already allocated users into these ranges.
External systems like FreeIPA allocated uid/gid numbers with reckless abandon directly into these ranges.
As a result we need to make two concessions.
We *secretly* still allow manual allocation of id's from 65536 through to 1879048191 which is the nspawn container range. This happens to be the range that freeipa allocates into. We will never generate an ID in this range, but we will allow it to ease imports since the users of these ranges already have shown they 'don't care' about that range. This also affects SCIM imports for longer term migrations.
Second is id's that fall outside the valid ranges. In the extremely unlikely event this has occurred, a startup migration has been added to regenerate these id values for affected entries to prevent upgrade issues.
An accidental effect of this is freeing up the range 524288 to 1879048191 for other subuid uses.
* Make the ubuntu_docker_builder.sh script a bit easier to use
- Entrypoint that installs dependencies on launch
- Echo hint on how to build deb packages
* Change debian packaging version string format to fix sort order
The sort order is important so that newer packages are seen as an update
and get installed, instead of apt preferring the older versions!
With these changes, a package is generated as `kanidm_Ubuntu_22.04_1:1.1.0~rc.15-dev~202401311334+c8a9e2c_x86_64.deb`
with the version string `1:1.1.0~rc.15-dev~202401311334+c8a9e2c`
Deb package version string comparison is Complex:
https://man7.org/linux/man-pages/man7/deb-version.7.html
With the previous versioning scheme for dev packages, the git hash
ended up getting prioritized over the date string, see for example:
`dpkg --compare-versions 1.1.0-rc.15-dev-202401100453666448f lt 1.1.0-rc.15-dev-20240120072786916a3; echo $?`
-> 1 (comparison failure)
A simple schema change avoiding most dashes could rescue the hash trouble:
`dpkg --compare-versions 1.1.0~rc.15-dev-202401100453+666448f lt 1.1.0-rc.15-dev-202401200727+86916a3; echo $?`
-> 0 (comparison success)
.. But, the second problem is seeing a stable release as newer:
`dpkg --compare-versions 1.1.0~rc.15-dev~202401100453+666448f lt 1.1.0; echo $?`
-> 1 (comparison failure)
.. Which can be solved by forcing the entire dev portion to not be
interpreted as a debian version by substituting tildes:
`dpkg --compare-versions 1.1.0~rc.15-dev~202401100453+666448f lt 1.1.0; echo $?`
-> 0 (comparison success)
.. But, old schema versions still seem newer due to their debian
version:
`dpkg --compare-versions 1.1.0-rc.15-dev-202401100453666448f lt 1.1.0~rc.15-dev~202401200727+86916a3; echo $?`
-> 1 (comparison failure)
Thus, the only solution is to change the scheme and increment the epoch value once
to force all lesser default epoch versions to be seen as older:
`dpkg --compare-versions 1.1.0-rc.15-dev-202401100453666448f lt 1:1.1.0~rc.15-dev~202401200727+86916a3; echo $?`
-> 0 (comparison success)
`dpkg --compare-versions 1:1.1.0~rc.15-dev~202401200727+86916a3 lt 1:1.1.0; echo $?`
-> 0 (comparison success)
* Drop epoch field from deb filenames
GitHub Actions enforces NTFS compatible artifact filenames, ergo the
colon required for the epoch field is banned. The epoc is still in the
version field itself, just not in the filename.
---------
Co-authored-by: Jinna Kiisuo <jinna+git@nocturnal.fi>
Martin Wurm
