Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 769977 - sys-apps/portage: exporting WGETRC=/dev/null breaks wget
Summary: sys-apps/portage: exporting WGETRC=/dev/null breaks wget
Status: RESOLVED OBSOLETE
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 377365
  Show dependency tree
 
Reported: 2021-02-10 23:02 UTC by Maciej Barć
Modified: 2023-12-27 23:48 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
bug (bug.txt,1.50 KB, text/plain)
2021-02-10 23:02 UTC, Maciej Barć
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Barć gentoo-dev 2021-02-10 23:02:18 UTC
Created attachment 686277 [details]
bug

exporting WGETRC into the running shell environment breaks fetching files with portage.
Propositoion: unset/ignore the env var.
Comment 1 Ben Kohler gentoo-dev 2021-02-10 23:10:39 UTC
But it works if you point WGETRC to an actual file, which is readable by portage user, right?
Comment 2 Maciej Barć gentoo-dev 2021-02-10 23:22:48 UTC
(In reply to Ben Kohler from comment #1)
> But it works if you point WGETRC to an actual file, which is readable by
> portage user, right?



Yes, it works when pointed to a file owned by portage.
Comment 3 Mike Gilbert gentoo-dev 2021-02-11 01:32:42 UTC
It is possible that the user might intentionally set WGETRC when invoking emerge. I don’t see why we would add special treatment for this. I would not classify this as a bug, and I think this should be closed as invalid.
Comment 4 Zac Medico gentoo-dev 2021-02-11 02:51:51 UTC
Since emerge is intended to pass through environment variables, it behaves as intended.

Reassigning to base-system to in case there's any desire to do something about this WGETRC=/dev/null behavior.
Comment 5 Maciej Barć gentoo-dev 2021-02-11 14:07:04 UTC
> about this WGETRC=/dev/null behavior.


It's not about the specyfic case of "/dev/null" only.
I discovered this becasue I eport WGETRC for wget to use my own wgetrc but I did not expect it will also be picked up by wget used by portage.
Comment 6 Mike Gilbert gentoo-dev 2021-02-11 14:26:58 UTC
I see from your log output that you are installing app-admin/sudo. If you run emerge using sudo, most environment variables will be unset, and that should resolve your problem.
Comment 7 Maciej Barć gentoo-dev 2021-02-11 16:16:47 UTC
(In reply to Mike Gilbert from comment #6)
> I see from your log output that you are installing app-admin/sudo. If you
> run emerge using sudo, most environment variables will be unset, and that
> should resolve your problem.


Heh, I just did this for example because I dont have sudo ;D I do su -l root and that's how I do stuff as root.
Resolving this with using sudo is a rather controversial method.
Comment 8 Ben Kohler gentoo-dev 2021-02-11 16:18:36 UTC
Setting WGETRC to a certain value then being surprised that emerge's wget respects that, seems a bit odd to me.
Comment 9 Maciej Barć gentoo-dev 2021-02-11 16:26:33 UTC
(In reply to Ben Kohler from comment #8)
> Setting WGETRC to a certain value then being surprised that emerge's wget
> respects that, seems a bit odd to me.



>CARGO_HOME
Remember?
Comment 10 Ben Kohler gentoo-dev 2021-02-11 16:28:42 UTC
If you are going to use that to argue that NO variables from the calling environment should be respected ever, I'm going to have to disagree.
Comment 11 Maciej Barć gentoo-dev 2021-02-11 16:31:03 UTC
(In reply to Ben Kohler from comment #10)
> If you are going to use that to argue that NO variables from the calling
> environment should be respected ever, I'm going to have to disagree.



Well, in my opinion WGETRC should be not respected or maybe the env var is would not be but it can be set in make.conf?
Comment 12 Maciej Barć gentoo-dev 2021-02-11 16:31:47 UTC
* or maybe the env var would not be but it can be set in make.conf?
Comment 13 Ben Kohler gentoo-dev 2021-02-11 16:33:13 UTC
As far as I know, the things we are using ENV_UNSET for, are things that might accidentally get automatically and cause problems.  Not for blacklisting any variable that the user might explicitly set which could possibly cause an emerge failure.
Comment 14 Maciej Barć gentoo-dev 2021-02-11 16:37:33 UTC
(In reply to Ben Kohler from comment #13)
> As far as I know, the things we are using ENV_UNSET for, are things that
> might accidentally get automatically and cause problems.  Not for
> blacklisting any variable that the user might explicitly set which could
> possibly cause an emerge failure.

irc.freenode.#gentoo-moz.weechatlog:345:2020-08-28 22:27:50     xgqt    Hey. with the CARGO_HOME env var exported tothe running shell firefox will try to install rust pkgs in that CARGO_HOME


I reported the CARGO_HOME problem (on IRC) cause I have set it manually
Comment 15 Ben Kohler gentoo-dev 2021-02-11 16:38:53 UTC
You should not be doing that in the root emerge context.

Stop doing these things.
Comment 16 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-02-11 16:53:58 UTC
I dare say this is a valid problem.

There is no real reason why root wouldn't be allowed to set WGETRC in his environment.  Since Portage uses wget internally and by default, it should be resilient to breakage caused by user's wgetrc contents or path mismatching its expectations.

If I set root's WGETRC to a file that is readable by root, emerge really shouldn't fail because it tries to read that file using portage user's permissions.
Comment 17 Mike Gilbert gentoo-dev 2021-02-11 18:58:24 UTC
If you want to propose an enhancement, please re-assign the bug back to dev-portage and send a patch.

This is certainly not a "bug", and is not going to be addressed by any action base-system would take.
Comment 18 Zac Medico gentoo-dev 2021-02-11 19:11:32 UTC
Raises the question of whether it's sane to let enviroment variables leak in by default.
Comment 19 Maciej Barć gentoo-dev 2021-02-11 19:13:30 UTC
(In reply to Zac Medico from comment #18)
> Raises the question of whether it's sane to let enviroment variables leak in
> by default.


Exactly. Maybe a switch like --use-env should be introduced and when it is off env will be cleared and only stuff in make.conf will be used.
Comment 20 Mike Gilbert gentoo-dev 2021-02-11 19:15:12 UTC
> This is certainly not a "bug", and is not going to be addressed by any action base-system would take.

To expand on that: if a change in behavior in wget itself is desired, the upstream mailing list would be the place to propose it. I don't think we want to get into the business of changing its behavior via local patching.

https://lists.gnu.org/mailman/listinfo/bug-wget
Comment 21 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-02-11 19:16:45 UTC
(In reply to Zac Medico from comment #18)
> Raises the question of whether it's sane to let enviroment variables leak in
> by default.

Sadly, it's necessary by design.  Otherwise, we'd have to maintain a huge whitelist of variables such as all eclass control variables, EXTRA_* stuff, etc.
Comment 22 Zac Medico gentoo-dev 2021-02-11 19:29:27 UTC
Something like the --use-env option suggested in comment #19 will probably work. However, if it's not enabled by default then we'll break anything relying on the current behavior. I imagine that the breakage will probably be acceptable, but the change will need to be well documented in order to minimize confusion. We can add the option before we enable it by default, so that people can start using it before it becomes default.
Comment 23 Alec Warner (RETIRED) archtester gentoo-dev Security 2021-02-11 19:45:38 UTC
(In reply to Zac Medico from comment #22)
> Something like the --use-env option suggested in comment #19 will probably
> work. However, if it's not enabled by default then we'll break anything
> relying on the current behavior. I imagine that the breakage will probably
> be acceptable, but the change will need to be well documented in order to
> minimize confusion. We can add the option before we enable it by default, so
> that people can start using it before it becomes default.

Or just let it break? Inaction is also action ;)

-A
Comment 24 Maciej Barć gentoo-dev 2023-12-27 23:48:56 UTC
I guess its just a matter of using different binary for fetching.