<Entei[m]>
<davidlt[m]> "You want to use package X in..." <- Oh right. I was thinking only in terms of building packages, not utilising them as dependency for other packages. Now it makes sense.
davidlt[m] has joined #fedora-riscv
<davidlt[m]>
kernel v6.4.6 and Rust 1.71.0 landed
<davidlt[m]>
Time to stop a bit, and think/plan branching F39 and building v6.5 kernel.
<davidlt[m]>
But my brain don't want this morning as it attempts to execute random commands like koji push :)
<davidlt[m]>
damn, I cannot even use keyboard this morning.
<Entei[m]>
The `koji add-user` adds user to pgsql database. I would create certificates for the user and copy them over in their accounts.
<Entei[m]>
So does hub authenticate users just based on the username?
<davidlt[m]>
Based on TLS or Kerberos5, depending on what you picked while configuring it.
<davidlt[m]>
BTW, GUADEC 2023 day 1 conference is live on YouTube.
<Entei[m]>
TLS. But the database doesn't define the certificate IDs or their hash.
<Entei[m]>
So anyone could just use the CA key and cert for them and copy the generates certs to their machine. But what does koji do to check? Say I add user _x_ through koji cli and copy it to machine with username _y_
<davidlt[m]>
Yeah, you add a user and generate certificates on your machine that hold private certificate.
<davidlt[m]>
The user gets 3 certificates (2 being important one). Koji CA root cert, user certificate, and another format of that for koji-web auth (if user wants to user koji-web interface, but I never do that).
<davidlt[m]>
The certificates never land in the database itself.
<davidlt[m]>
(IIRC)
<davidlt[m]>
Koji user common name in the certificate to match Koji user to the certificate.
<Entei[m]>
Yeah but there doesn't seem to be mechanism to check if this user (who holds valid CA cert and user cert in their koji config) was actually authenticated to do anything on the hub, even ping the hub.
<Entei[m]>
And then there's permissions for users. If the client is having a username **x** and I change the permissions for the user **y**, how does that associate?
<davidlt[m]>
Again IIRC, brain is not collaborating with me today.
<davidlt[m]>
The permissions are stored in Koji database.
<davidlt[m]>
Basically the most important thing is certificate. As long as someone has it it has access.
<davidlt[m]>
Because you can look at the certificate and see the user name there.
<davidlt[m]>
It's not mutli-factor auth thing unless you place a password on the certificate during the creation time.
<davidlt[m]>
F38 is sycned, but I did something stupid which makes it harder to figure out which 100+ packages were added 😄
<davidlt[m]>
152 new packages, majority of it are Rust, then Python, PHP, Golang.
<davidlt[m]>
Basically everything as expected.
<davidlt[m]>
Time to dump a list for F39 and check the tags.
<davidlt[m]>
If you change it, you need to generate a new certificate.
<davidlt[m]>
The builders don't need to have a valid FQDN.
<davidlt[m]>
Those "hostname" can be fake too. Don't need to be real.
<Entei[m]>
davidlt[m]: Alright. So authorisation is based on username then (authentication with certificate)
<davidlt[m]>
It's based on certificate.
<davidlt[m]>
The certificate holds the username.
<davidlt[m]>
`Subject: <..>, CN=davidlt`
<davidlt[m]>
The Common Name field in the certificate has the username for Koji.
<Entei[m]>
I see. So the best practice would actually be to use FQDN everywhere. We get static local IPs and DHCP provided names.
<Entei[m]>
Would prevent the confusion while managing hosts and users
<davidlt[m]>
Yeah, it helps with admin work, but otherwise it can be anything you want.
<davidlt[m]>
It just needs to match with host/user in Koji database. That's the only requirement.
<davidlt[m]>
Koji is "pull" based system. So the builders take jobs from the Koji, but Koji itself doesn't push anything to them.
<davidlt[m]>
The only domain that is important is for Koji Hub.
esv__ has joined #fedora-riscv
esv_ has quit [Ping timeout: 246 seconds]
<davidlt[m]>
Ah, I got an email about BeagleV-Ahead, but it went to spam.
<Entei[m]>
Do you think it would be feasible to use as builder considering it's small emmc? The only expansion options are SD card (slow) and a USB 3.0 connector.
<davidlt[m]>
No.
<davidlt[m]>
It's not designed to be a builder.
<davidlt[m]>
And way too little RAM on it.
<davidlt[m]>
No fast storage.
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
<davidlt[m]>
Stupid me, I forgot to rebuild kernel-headers and kernel-tools for v6.4.X
<conchuod>
davidlt[m]: 3 more bits of peripheral enablement queued up for 6.6 for you.
<conchuod>
(for the vf2)
jcajka has quit [Quit: Leaving]
<davidlt[m]>
conchuod: what's still missing? Is it only PCIe and USB?
<conchuod>
I think the eMMC is missing too
<davidlt[m]>
eMMC or does that also incl. microSD card?
<davidlt[m]>
I don't really care about eMMC much as it's better to spend money on any M.2 NVMe for VF2 :)