Use of .netrc for the cURL channel

[Cirujano Cuesta, Silvano]

Hi there,

Currently, the SWUpdate cURL channel only considers any available .netrc configuration if a proxy is enabled (as per [1]). In theory, it provides the necessary proxy credentials, but it would also automatically be taken into account by cURL for the various services that provide the artifacts to be downloaded.

We’re considering using .netrc for the artifact-providing services, both with and without a proxy. We have two options to achieve this:

1. The simplest approach: make the cURL channel always consider any available .netrc configuration.
2. The most flexible option: make it configurable through a configuration file or a CLI flag.

I’d prefer option 1 because it’s straightforward to implement, and an integrator should never provide a .netrc configuration that isn’t considered. However, I wanted to seek a second opinion: is there a compelling reason not to go with option 1?

Best regards,
Silvano

[1]: https://github.com/sbabic/swupdate/blob/1b0490049bb86053d91df2a14a0557b1fd59550e/corelib/channel_curl.c#L810

—
Silvano Cirujano Cuesta

[Stefano Babic]

Hi Silvano,

On 4/14/26 18:09, 'Cirujano Cuesta, Silvano' via swupdate wrote:
> Hi there,
>
> Currently, the SWUpdate cURL channel only considers any available .netrc configuration if a proxy is enabled (as per [1]). In theory, it provides the necessary proxy credentials, but it would also automatically be taken into account by cURL for the various services that provide the artifacts to be downloaded.

This is already bad enough.

>
> We’re considering using .netrc for the artifact-providing services, both with and without a proxy. We have two options to achieve this:
>
> 1. The simplest approach: make the cURL channel always consider any available .netrc configuration.
> 2. The most flexible option: make it configurable through a configuration file or a CLI flag.
>
> I’d prefer option 1 because it’s straightforward to implement, and an integrator should never provide a .netrc configuration that isn’t considered. However, I wanted to seek a second opinion: is there a compelling reason not to go with option 1?

The current approach (only for proxy, that is already a niche in the
user world) has the flaw that the .netrc of the user who belongs
SWUpdate (often root for the core) is silently searched. When privilege
separation is set and suricatta / webserver / delta downloader /... are
runningwith a different user, othe r.netrc take place. This leads to a
quire confusing scenario, and maybe security leaks (together with DNS
attacks).

I will prefer to drop the current approach and if this will be available
to any downloader, also CURLOPT_NETRC_FILE must be set and must be
mandatory. The filename should be set as usual via configuration file
and via CLI (but like certificate, it could be also fine if this is
possible only via configuration file).

An option can be to create the ".netrc" (that is not anymore ~/.netrc)
from the configuration file, so that the integrator does not need to
maintain multiple files for SWUpdate. SWUpdate must have access to both
the configuration file (swupdate.cfg) and ".netrc", that is having the
machine logins inside the configuration file does not seem to me a
security issue.

So I do not want to go to 1), I am just allowing .netrc in the current
software, but to extend the usage I will switch to a more structured
solution. With privilege separation and multiple users to run SWUpdate's
processes, the integrator won't have to do something, but he has also no
idea what is going on.

Best regards,
Stefano


--
_______________________________________________________________________
Nabla Software Engineering GmbH
Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596
Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
E-Mail: sba...@nabladev.com