Making test-functions strict required some test adjustments where we
incorrectly expected an number while we receive in fact a string. As
getAttribute() returns either a string or null.
Flatpak made assertions where a field could be present but not visible
which can cause race conditions where we would input values before the
flatpak browser had a chance to render it.
It was also possible to click the login button before the browser had
registered an input, which could make the button still disabled.
Likewise when logging out we could be loading a page and then executing
logout before the shell had a chance to render, meaning the logout
button doesn't exist.
Signed-off-by: Freya Gustavsson <freya@venefilyn.se>
Some tests are verging on timeouts and sometimes encounter them during
tests. This was in particular true during initial experimentation on why
ubuntu-latest runner migration show failed tests for flatpak tests.
Related-to: https://github.com/cockpit-project/cockpit/pull/23713
Signed-off-by: Freya Gustavsson <freya@venefilyn.se>
Several files, including the deployment guide index page, link to the
old AsciiDoc guide on our website whereas our new docs site is published
under docs subdomain using Antora. While these links will work in the
future thanks to redirects we should update the links where we can to
avoid this unnecessary redirect.
Other changes include changing links from being header anchors within a
single-page to a multi-page navigation with asciidoctor's xref. This
change only applies to links within the same module and doesn't change
any links from guide to manpage for example. That will be tackled in a
future commit as it also has to deal with compiling to manpages.
Signed-off-by: Freya Gustavsson <freya@venefilyn.se>
Many popular containers set standardised annotations as a label to allow
container UI's to display additional container image details. Set a
subset of annotations which are useful for administrators running a
cockpit-ws container.
https://specs.opencontainers.org/image-spec/annotations/
In a future commit we want to add labels to our ws-container, this
becomes easier when if we have a centralised location where we build the
cockpit-ws image.
Replace full LGPL/GPL/MIT/BSD license header with
SPDX-License-Identifier in all source files. This is more concise and
makes the license information machine readable.
Keep the full text of ISC for src/common/cockpitbase64.[hc], it's small
enough and only used in this pair of files. Also keep the CC-BY-SA
paragraph in pkg/storaged/icons/gnome-icons.jsx as explained in the
previous commit.
See https://reuse.software/spec-2.0/#2-include-a-copyright-notice-and-license-in-each-filehttps://issues.redhat.com/browse/COCKPIT-1742
This complicates the run script quite a bit, so port it to Python.
Add explicit handling for each of the options that we used to pass
through to cockpit-ws.
We handle fact that we don't have systemd inside of the container by
pretending to be systemd: we bind the unix socket for cockpit-ws and
pass it through via the LISTEN_FDS mechanism: this avoids needing to add
support for unix sockets to cockpit-ws. We also handle the binding of
the TCP socket ourselves and pass it through to either cockpit-tls or
cockpit-ws depending on if we're using TLS or not.
The container was the last user of the native TLS support in cockpit-ws,
which means we can now remove it, reducing the amount of work we need to
do in order to support post-quantum cryptography.
https://issues.redhat.com/browse/COCKPIT-1330
When iterating locally it helps if we can avoid having to repeat the
"download the packages from the Fedora servers" step, which is currently
run every time.
We can do that by separating it to a separate step that runs *before* we
copy in the entire contents of what becomes the /container directory
(which changes on every iteration).
We install cockpit-bridge and cockpit-ws up front now even though they
will still be installed later by install.sh because we want the
dependencies (and I couldn't find any easy way to say "just install the
runtime dependencies of these packages).
We don't bother with any "layer avoidance" techniques here because this
is just the builder container which doesn't become part of the final
result.
Add a `make ws-container-build-tree` target which copies the bundles and
binaries from the build tree into the container image. This is much
faster than a full image-prepare and building rpms in a VM.
This could be optimized further to not always reinstall the rpms during
each container build, but reuse these layers. However, the Containerfile
currently does the `ADD .` before the dnf install, and all the install
steps happen in an order which breaks efficient caching. This is
annoyingly hard to fix (cue: `COPY` and `ADD` barf with nonexisting
files/directories, even with globbing).
Only use when you know what you are doing -- if it breaks, you get to
keep both halves.
Allows authentication to be `localhost`-only.
This is a minor security feature that allows you to use public key authentication for SSH
while keeping Cockpit-based authentication to username and password.
Related-to: https://github.com/ublue-os/ucore/issues/275
Related-to: https://github.com/ublue-os/ucore/pull/286
Co-authored-by: Freya Gustavsson <freya@venefilyn.se>
Update `make-dist` and `release` to produce a runtime node_modules tarball.
`tools/node-modules runtime-tar` uses `jq`, so add that as a packit
source build dependency.
Adjust the consumers of `make-dist` accordingly. This isn't being used for
anything yet, this will be a follow-up.
We started getting errors for our flatpak CI runs a few weeks ago. Which
coincided with an upstream infrastructure issue which would explain the
screenshots error. After infra was fixed and the fact that we didn't get
any successful runs, something else was going on.
Turns out that `flatpak-builder` had a release which changed the
behaviour of `--compose-url-policy` to default to `partial` instead of
`full` which was used before. Our fix is simple, just change it back to
`full`
Fixes: https://github.com/cockpit-project/cockpit/issues/22444
Related-to: https://github.com/flatpak/flatpak-builder/pull/652
Signed-off-by: Freya Gustavsson <freya@venefilyn.se>
* Run build on both x86_64 and arm64 runners, merge results in manifest
* Make registry repository and tag configurable
* Remove `push` command from `release.sh` script
This makes it a bit easier to debug/understand failures which only
happen in CI. It goes directly to stdout, as it's not easy to write that
into a file -- so it's awkward, but better than nothing.
Flathub already mirrors our screenshots to https://dl.flathub.org/media.
Tell flatpak builder to rewrite the manifests to actually point to the
mirror. This fixes the recent `appstream-external-screenshot-url` error.
Fixes#21643
In unprivileged mode, support connecting to an already running SSH agent
for sharing SSH private keys.
Thanks to Anton Engelhardt <engelhardt.anton@gmail.com> for the idea and
initial implementation sketch!
Fixes#21170
`cockpit-session` isn't meant to work in the container: ws runs with
`--local-ssh` and everything happens via SSH, so we can just as well
drop it. This gets rid of the useless initial cockpit-session call for
the opportunistic "Negotiate" (Kerberos) authentication.
We temporarily also have to remove the program in
test/ws-container.install, until our Fedora 40 image gets a cockpit/ws
version which doesn't have it installed any more, i.e. when this commit
lands, gets released, published to quay.io, and into the fedora-40 image
rebuild.
Kdump, Networking, SELinux, Storaged, and Software Updates are all fine
and useful for beiboot mode. Apps doesn't, but that's hidden by the
manifest condition.
type="local" has been invalid for AppStream for a long time now, only
"stock" or "remote" are valid. Also, app specific icons must be placed
into /usr/share/icons/hicolor/, not /usr/share/pixmaps/. See [1] for
details.
Debian's latest lintian started to complain about invalid AppStream
metadata more loudly (via `appstreamcli validate`), causing a cockpit
build failure on our CI as we fail the build on lintian warnings.
[1] https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/#icons
Nothing is using this code anymore. All that's left in this directory
are a few test resources: we'll deal with those in the next commit.
Clean up a few stray references in the build system and packaging: in
paticular, remove --enable flags for both PCP and PolKit.
This provides similar functionality as the Client, so that the ws
bastion container can connect to machines which don't have any Cockpit
packages installed.
Install cockpit-system and cockpit-networkmanager into the container
(we'll likely expand this in the future, but let's start small). Take
care to only unpack the RPMs, to avoid installing e.g. NetworkManager
and other big dependencies into the container -- they are useless there.
Update the documentation accordingly. While at it, add an introduction
paragraph what Cockpit is.
https://issues.redhat.com/browse/COCKPIT-954
Nothing uses this any more, superseded by cockpit-beiboot. This gets rid
of the libssh build dependency.
Drop the `Provides: cockpit-ssh` from Debian. No package ever related to
that virtual package name, and it's meaningless these days.
cockpit.beiboot has feature parity with cockpit-ssh, so switch the
default direct remote session program to that. Use
`--remote-bridge=always` mode for the time being in ws and the
container; we are going to support that eventually, but let's not change
everything at once.
Change ws' detection of remote login availability to "cockpit-bridge and
ssh are available". This involves forking a shell now (for running the
`command` shell builtin), add an expected message to
`TestConnection.testHttpsInstanceDoS`.
Drop the `COCKPIT_SSH_BRIDGE_COMMAND` env var documentation,
cockpit-beiboot does not use that.
Rename `testLoginSshBeiboot` to `testSSH`. This test covers a few corner
cases that other tests don't, and it's very convenient for development
to have a nondestructive test which covers all aspects of bastion host
SSH login.
Adjust some error messages in the tests.
https://issues.redhat.com/browse/COCKPIT-1029
That key is never interactively validated with cockpit-ssh in the
default configuration: That reads cockpit.conf's [Ssh-Login] host=
option (defaulting to 127.0.0.1) and ignores that host's key. This is
fine for 127.0.0.1, but dangerous and unexpected for external hosts:
These should *always* use proper SSH host key validation and change
detection.
That cockpit.conf option is normally meant to set the default remote
host for the login page (evaluated in ws), and either way isn't even
documented in our manpage.
cockpit-beiboot does not read this option, and really shouldn't. So just
hardcode 127.0.0.1 there.
Adjust the flatpak test accordingly.
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.
We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see #19668.
So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.
While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:
* For a previously unknown host and a successful login, we only get the
full host key as part of the GET /login's `login-data` response. So
defer updating our localStorage's `known_hosts` database during the
conversation until that happens.
* For a failed login (like wrong password) after already confirming the
key change, get the host key from the protocol error message.
* ssh (and thus ferny/beiboot) don't report changed host keys as part
of conversation, but immediatley abort. So remember that state in
`ssh_host_key_change_host`, and re-attempt the login without sending
known_hosts data. Our usual logic in `do_hostkey_verification()` will
notice the change and present the correct dialog.
Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
