Summary: | sys-apps/portage-2.1.10.3 emerge --info output contains private data | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Sergey S. Starikoff <Ikonta> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Sergey S. Starikoff
2011-08-17 09:46:52 UTC
I'd say this bug is invalid. a) You shouldn't store passwords as plain text, but you some authentication mechanism. b) FETCH_COMMAND is necessary information to debug fetch issues and should consequently be part of emerge --info. (In reply to comment #1) > I'd say this bug is invalid. > > a) You shouldn't store passwords as plain text, but you some authentication > mechanism. > > b) FETCH_COMMAND is necessary information to debug fetch issues and should > consequently be part of emerge --info. Even so, I think it would be reasonable to process variables with a regular expression, like the fetch() function does: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=6d4cf62440f60b2e41a9e8e824b876093f6517c3 (In reply to comment #0) > Just today while reporting a bug I've discovered very unpleasant issue: > > I access public network via auth-required proxy server. > For correct operability of portage I've redefined in /etc/make.conf > FETCHCOMMAND and RESUMECOMMAND to: > FETCHCOMMAND="/usr/bin/wget -t 5 -T 60 --passive-ftp --proxy-user="myuser" > --proxy-password="mypassword" -O \"\${DISTDIR}/\${FILE}\" \"\${URI}\"" > RESUMECOMMAND="/usr/bin/wget -c -t 5 -T 60 --passive-ftp --proxy-user="myuser" > --proxy-password="mypassword" -O \"\${DISTDIR}/\${FILE}\" \"\${URI}\"" I'd suggest that you put command in a shell script with appropriate permissions, and have FETCHCOMMAND/RESUMECOMMAND call the shell script. If the pattern was a URI pattern, then I'd go ahead and filter it. However, recognizing the --proxy-user and --proxy-password options that are unique to wget it a little too much to ask. (In reply to comment #3) > I'd suggest that you put command in a shell script with appropriate > permissions, and have FETCHCOMMAND/RESUMECOMMAND call the shell script. > Thank you. May be the issue could be solved by adding some user-side filter, by default disabled (and empty)? Now I'm thinking about writing some bash-script for filtering emerge --info output (and start to use emerge-info.sh, solving my issue, instead of emerge-info). For some paranoids domain (and perhaps IP) data also should (wanted to) be filtered. We could add a variable called something like PORTAGE_INFO_VAR_FILTER where you would have a regular expression that would be used like grep -v to filter matched lines out of the variable output. May be it is better to use not grep -v but sed-like filter (with variable field-mask list). For example: PORTAGE_INFO_VAR_FILTER is set (contains private data, value doesn't included). FETCHCOMMAND="/usr/bin/wget -t 5 -T 60 --passive-ftp --proxy-user="myuser" --proxy-password="mypassword" -O \"\${DISTDIR}/\${FILE}\" \"\${URI}\"" is not excluded from emerge --info output, but modified to something like: FETCHCOMMAND="/usr/bin/wget -t 5 -T 60 --passive-ftp --proxy-user="gentoo" --proxy-password="secret" -O \"\${DISTDIR}/\${FILE}\" \"\${URI}\"" As was shown in bug #398615 for proxy credentials it's more correct to use system-wide fetch utility configuration (if used default net-misc/wget --- /etc/wgetrc). But other private data (user names and IPs) normally should be filtered. It seems to be mostly my mistake. I also prefer to use by default for most cases '--verbose' option (issue described in bug #376989), which extends verbosity much above necessary. Currently using alias: alias einfo="emerge --ignore-default-opts --info" almost completely solves issue (the only private data present in output is internal address of local rsync mirror). So, adding to the end of 'emerge --verbose --info' command warning about private data will completely solve this issue. Just attention. And don't use --verbose option for bugzilla's system desc. For rather long ago Bugzilla's quotas reminds to do so. |