Initially requested through different tracker but creating it here for awareness and linking with other c10s infra tasks
/cc: @fche
Metadata Update from @arrfab: - Issue tagged with: blocked, centos-build-pipeline, centos-stream, feature-request
Metadata Update from @arrfab: - Issue assigned to arrfab
debuginfod role checked and slightly modified and confirmed that now that we have pre-staged 10-stream pkgs, they are already landing on debuginfod backend machine
Metadata Update from @arrfab: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Fabian, okay, I see the new files files starting to come down to under /srv/debuginfod_store/9-stream/10-stream, but the directory has too restrictive permissions for debuginfod to actually see them. Is that intentional?
yes, because it's "pre-staged", so once once Stream team will be ok for a real release, permissions will be updated and reflected everywhere on the mirror network, including then to debuginfod backend node
The data is starting to flow. One question: are the RPMs held at the debuginfod server the ones from the "100% signed" compose? I was expecting to see IMA per-file signatures on them also, but:
rpm -q --qf='[%{FILESIGNATURES}\n]' -p $RPMFILE
comes up empty.
I know that very few packages in the bootstrap phase were only signed with gpg but not IMA but almost all packages there were IMA signed. Happy to discuss that "internally" if needed
bootstrap
Correction: interestingly, a bunch of the c10s rpms on the debuginfod server ARE IMA signed. It's just that the rhel8 version of rpm/librpm does not recognize them that way, so the server cannot extract those headers. The same files copied onto a modern Fedora host see the signatures just fine. So whatever the problem is, it's not a debuginfod server / file copying / ima signing one, it seems.
Log in to comment on this ticket.