Authentication in fedpkg
by Björn Persson
I recently added two new packages to Fedora. Things have changed a bit
since the previous time I did this, and more things can now be done
through fedpkg. I would like to share my experience with this. This is
what the procedure is like for a volunteer who only sometimes works on
Fedora stuff:
· When the package has passed review I need to request a Git repository.
There's a handy command for that: "fedpkg request-repo". But before I
can run that I must log in to a special web interface and get an API
token that I must paste into a configuration file that I've otherwise
never heard of. This comes across as a half-baked design.
The token expires, so next time I add a package I'll have to do this
again. I won't remember the URL, nor the pathname of the file, so I'll
have to look them up every time.
· Once the repository exists I need to clone it with "fedpkg clone".
This requires SSH authentication. This is the method I like best,
partly because it uses a key encrypted with a master passphrase, so
that the passphrase I type never leaves my workstation, but also because
it's the same SSH that I use all the time, so I already know how to
manage it. SSH key management is actually rather clumsy; I'm just used
to it.
· The next step is to add files to the repository and upload the source
tarball. Again there's a handy command: "fedpkg import". But that fails
halfway through because I'm not authenticated with Kerberos. It doesn't
even ask me for a password. Instead I have to run a kinit command to
authenticate. This gives the impression that somebody completely forgot
to implement the authentication bit.
Another problem with this method is that it expects me to directly type
in the shared secret. I can't have the secret stored in a keyring
encrypted with a master passphrase.
Then I retry "fedpkg import", but that fails because of the files it
added to Git the first time, and I have to upload the tarball with
"fedpkg new-sources" instead.
· Before I build the new package I may need a buildroot override.
"fedpkg override" is the command, and it appears to use yet another
authentication method. This one is actually capable of asking for a
password. It doesn't say which password it wants, but I tried the FAS
password and it was apparently right. It even seems to cache the
password or some authentication token, because it doesn't ask again
when I request a second buildroot override.
This is better thought-out than request-repo and the various upload and
build commands, but even this method expects me to type in the shared
secret. There is no keyring option as far as I can tell.
One task, one front-end program, four different authentication methods,
each with its own idiosyncrasies. It's not even four separate accounts.
Everything hinges on the same FAS password. (Even SSH keys are managed
with the FAS password.) Why do I have to authenticate to the same
account four times in four different ways?
I'm sorry to be complaining. I know everybody has too much to do (myself
included), but seriously folks, this needs to be improved. This is not
a good user experience. I hope the plans to retire some less important
services will lead to somebody finding some time to improve the user
interface for these essential tasks.
I would think that the infrastructure team's lives would be easier with
fewer authentication protocols to worry about, but as a user I'd be
satisfied if the incoherence would be hidden behind a consistent user
interface. Here are some improvements I would like to see:
1: If the various upload and build commands could ask for the FAS
password and perform the Kerberos authentication, instead of just
giving up, then that would be a good start.
2: If the request-repo command and its relatives could ask for the FAS
password and use that to acquire their API tokens under the hood, then
that would greatly improve usability.
3: Once points 1 and 2 are done, it would be great if all commands that
need the FAS password were able to fetch it from a common keyring. The
first time the keyring program would ask me to unlock the keyring with
the master passphrase. The master passphrase wouldn't be sent anywhere;
it would only be used for decrypting the FAS password. After that the
password would be automatically fetched from the keyring each time it's
needed, just like it works with the SSH agent. That way I'd only need
to remember the master passphrase, and I wouldn't need to manually copy
the FAS password from the keyring to various password prompts.
4: If point 3 would be implemented, then the FAS password would be about
as user-friendly as an SSH key. Then, and not before, it might make
sense to use Kerberos authentication in SSH, if the Kerberos bits were
able to fetch the password from the keyring described in point 3.
5: This point is less important than the others, but it would also be
nice if Pagure would refrain from spamming me with warnings that my API
key (token, key, whatever) is about to expire and the sky is going to
fall unless I get a new one. I'm not using that token in any
"non-interrupted service". I'll get a new token next time I add a new
package, which may be years from now, if that system is still in use by
then.
Björn Persson
4 years, 8 months
Rust applications & i686
by Igor Gnatenko
Hello fellows,
So that now i686 is no longer exists (I mean as an image), is there
reason to produce i686 binaries for applications written in Rust? That
also would mean we would stop testing i686 as a platform for crates,
but I honestly love this because very often builds fail due to LLVM
OOM.
Thoughts?
4 years, 8 months
dnf & rpm-devel both seem to be uninstallable in the Rawhide
buildroot
by Richard W.M. Jones
The error is:
DEBUG util.py:585: BUILDSTDERR: Error:
DEBUG util.py:585: BUILDSTDERR: Problem 1: package rpm-devel-4.15.0-0.beta.2.fc31.1.x86_64 requires librpmsign.so.9()(64bit), but none of the providers can be installed
DEBUG util.py:585: BUILDSTDERR: - package rpm-devel-4.15.0-0.beta.2.fc31.1.x86_64 requires rpm-sign-libs(x86-64) = 4.15.0-0.beta.2.fc31.1, but none of the providers can be installed
DEBUG util.py:585: BUILDSTDERR: - conflicting requests
DEBUG util.py:585: BUILDSTDERR: - nothing provides libimaevm.so.0()(64bit) needed by rpm-sign-libs-4.15.0-0.beta.2.fc31.1.x86_64
DEBUG util.py:585: BUILDSTDERR: Problem 2: package dnf-4.2.7-3.fc31.noarch requires python3-dnf = 4.2.7-3.fc31, but none of the providers can be installed
DEBUG util.py:585: BUILDSTDERR: - package python3-dnf-4.2.7-3.fc31.noarch requires python3-rpm >= 4.14.0, but none of the providers can be installed
DEBUG util.py:585: BUILDSTDERR: - conflicting requests
DEBUG util.py:585: BUILDSTDERR: - nothing provides libimaevm.so.0()(64bit) needed by python3-rpm-4.15.0-0.beta.2.fc31.1.x86_64
DEBUG util.py:585: BUILDSTDERR: Problem 3: package python3-dnf-plugins-core-4.0.7-2.fc31.noarch requires python3-dnf >= 4.2.1, but none of the providers can be installed
DEBUG util.py:585: BUILDSTDERR: - package dnf-plugins-core-4.0.7-2.fc31.noarch requires python3-dnf-plugins-core = 4.0.7-2.fc31, but none of the providers can be installed
DEBUG util.py:585: BUILDSTDERR: - package python3-dnf-4.2.7-3.fc31.noarch requires python3-rpm >= 4.14.0, but none of the providers can be installed
DEBUG util.py:585: BUILDSTDERR: - conflicting requests
DEBUG util.py:585: BUILDSTDERR: - nothing provides libimaevm.so.0()(64bit) needed by python3-rpm-4.15.0-0.beta.2.fc31.1.x86_64
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
4 years, 8 months
s390x rawhide issues?
by Tom Callaway
One of my packages (alienarena) fails to build in rawhide on s390x (and
only that arch), but the build log shows it never even starts. When I look
at the root log, I see this:
DEBUG util.py:585: BUILDSTDERR: error: unpacking of archive failed on file
/builddir/build/SOURCES/alienarena-7.71.0-svn5638.tar.xz;5d41b327: cpio:
read failed - Inappropriate ioctl for device
DEBUG util.py:585: BUILDSTDERR: error:
/builddir/build/originals/alienarena-7.71.0-3.fc31.src.rpm cannot be
installed
Is something unhappy on s390x on rawhide?
Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=36706646
Thanks in advance,
Tom
4 years, 8 months
Mock - signal reaction
by Jan Buchmaier
Now I'm working on signal SIGTERM handling and I would like to kill all processes related to the main mock process.
What do you think is it a good idea to kill all processes, or do we want to kill the main process only?
And what about SIGINT so-called KeyInterrupt in python? Same reaction?
4 years, 8 months
Fedora 31 Self-Contained Change proposal: Simply reclaim disk space
in Anaconda
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Anaconda_Reclaim_Disk_Space
== Summary ==
The installer shows the Resize Disk Space dialog to reclaim disk space
for the automatic partitioning in the graphical user interface. The
Anaconda team would like to replace this dialog with a simple list of
predefined choices.
== Owner ==
* Name: [[User:Vponcova| Vendula Poncova]]
* Email: vponcova(a)redhat.com
== Detailed Description ==
The installer shows the Resize Disk Space dialog to reclaim disk space
for the automatic partitioning in the graphical user interface. The
Anaconda team would like to replace this dialog with the following
list of choices:
* Use all disk space
* Use free space available for use
* Replace existing Linux system(s)
* Shrink or remove existing partitions
The first three options will redirect users to the Installation
Summary screen. The automatic partitioning will be configured based on
the selected action.
The last option will redirect users to the Manual Partitioning screen.
Users can shrink or remove existing partitions, automatically create
new partitions and leave the screen.
The Manual Partitioning screen supports all actions of the Resize Disk
Space dialog, so it doesn't make sense to have two user interfaces
with the same functionality.
== Benefit to Fedora ==
Simple predefined choices should improve the user experience for
users, who are not interested in shrinking or removing specific
partitions. Beginners can use all or free disk space without other
interaction. Advanced users can quickly reinstall their systems and
virtual machines.
== Scope ==
* Proposal owners: Implement the new dialog window for the graphical
user interface. The support for the dialog actions is already
implemented for the text user interface and kickstart installations.
It is a very small and isolated change.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
During the Fedora installation, it will be easier to set up the
automatic partitioning in the graphical user interface. Users can
choose with one click to use all disk space, all free space or to
replace existing Linux systems.
These options are supported also in the text user interface and
kickstart files, so users might be already familiar with them.
Advanced users can choose to shrink or remove existing partitions.
They will be redirected to the Manual Partitioning screen, where they
can delete and shrink partitions and automatically generate partitions
for the new installation. However, users have much more flexibility at
this point. They can create a fully customized configuration without
having to revisit the Installation Destination screen.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Revert the changes in Anaconda.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 8 months