sysupdate: accept provider: URLs in transfer sources

Since systemd-pull now understands "provider:[/path/to/socket]/name"
URLs, allow them in the Path= setting of url-file and url-tar sources,
wherever HTTP/HTTPS URLs are accepted. Manifests and payloads are then
acquired from the specified io.systemd.ResourceProvider service, with
the same verification as for web servers. Document the scheme, and how
component providers can use it to serve their own resources.

Fixes: #33351

man/sysupdate.components.xml

@@ -376,6 +376,15 @@ SuggestOnVirtualization=!vm
     message is logged. The default component (i.e. <filename>sysupdate.d/</filename>) is always taken from
     the file system.</para>
 
+    <para>Instead of pointing its transfers to resources on a web server, a provider may also serve these
+    resources itself. In that case, it must implement the generic
+    <constant>io.systemd.ResourceProvider</constant> Varlink interface (typically on the same socket), and
+    use URLs of the form
+    <literal>provider:[/run/systemd/sysupdate/provider/<replaceable>name</replaceable>]/<replaceable>resource</replaceable></literal>
+    in the <varname>Path=</varname> field of the sources of its transfers, see
+    <citerefentry><refentrytitle>sysupdate.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details.</para>
+
     <para>Since the definitions of provider-backed components do not live in the file system, the
     <command>enable-component</command>, <command>disable-component</command>,
     <command>enable-feature</command> and <command>disable-feature</command> commands of

man/sysupdate.d.xml

@@ -167,11 +167,12 @@
     <orderedlist>
 
       <listitem><para>Resources of type <literal>url-file</literal> encapsulate a file on a web server,
-      referenced via a HTTP or HTTPS URL. When an update takes place, the file is downloaded and decompressed
-      and then written to the target file or partition. This resource type is only available for sources, not
-      for targets. The list of available versions of resources of this type is encoded in
-      <filename>SHA256SUMS</filename> manifest files, accompanied by
-      <filename>SHA256SUMS.gpg</filename> detached signatures.</para></listitem>
+      referenced via a HTTP or HTTPS URL, or a resource offered by a local resource provider service,
+      referenced via a <literal>provider:</literal> URL (see <varname>Path=</varname> below). When an update
+      takes place, the file is downloaded and decompressed and then written to the target file or
+      partition. This resource type is only available for sources, not for targets. The list of available
+      versions of resources of this type is encoded in <filename>SHA256SUMS</filename> manifest files,
+      accompanied by <filename>SHA256SUMS.gpg</filename> detached signatures.</para></listitem>
 
       <listitem><para>The <literal>url-tar</literal> resource type is similar, but the file must be a
       <filename>.tar</filename> archive. When an update takes place, the file is decompressed and unpacked
@@ -639,6 +640,21 @@
         names listed in the manifest file in case an update is executed and a resource shall be
         downloaded.</para>
 
+        <para>Alternatively, for these two source types a URL of the form
+        <literal>provider:[<replaceable>socket</replaceable>]/<replaceable>resource</replaceable></literal>
+        may be specified, which refers to a resource offered by a local service implementing the
+        <constant>io.systemd.ResourceProvider</constant> Varlink interface on the
+        <constant>AF_UNIX</constant> socket <replaceable>socket</replaceable> (an absolute path). The
+        <replaceable>resource</replaceable> part is an opaque name the service understands, which may contain
+        slashes, but no <literal>.</literal> or <literal>..</literal> components. Such URLs are suffixed and
+        otherwise treated exactly like HTTP/HTTPS URLs: <filename>/SHA256SUMS</filename>,
+        <filename>/SHA256SUMS.gpg</filename> and the file names from the manifest are appended to the
+        <replaceable>resource</replaceable> part and requested from the service via that interface.
+        Verification hence works the same way as for HTTP/HTTPS sources; in particular
+        <varname>Verify=yes</varname> requires the service to offer the signature file too. This is
+        primarily useful in combination with component providers, see
+        <citerefentry><refentrytitle>sysupdate.components</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
         <para>For all other source resource types this must be a local path in the file system, referring to
         a local directory to find the versions of this resource in.</para>
 

src/sysupdate/sysupdate-transfer.c

@@ -603,9 +603,9 @@ static int transfer_finalize(Transfer *t, const char *origin, unsigned line, Has
                  * sources. That's mostly for testing, since it relieves us from having to set up a HTTP
                  * server, and CURL abstracts this away from us thankfully. */
                 if (RESOURCE_IS_URL(t->source.type))
-                        if (!http_url_is_valid(t->source.path) && !file_url_is_valid(t->source.path))
+                        if (!http_url_is_valid(t->source.path) && !file_url_is_valid(t->source.path) && !provider_url_is_valid(t->source.path))
                                 return log_syntax(NULL, LOG_ERR, origin, line, SYNTHETIC_ERRNO(EINVAL),
-                                                  "Source path is not a valid HTTP or HTTPS URL: %s", t->source.path);
+                                                  "Source path is not a valid HTTP, HTTPS, file, or provider URL: %s", t->source.path);
         }
 
         if (strv_isempty(t->source.patterns))