This was kinda done on purpose. -Sp can be called by anyone, whereas the pacman.d files may be locked down with special (600) permissions. I consider adding user/pass a security hole.

It's not specified that -Sp url's are to be used with wget, and if they are, it's up to you to authenticate.

Dan, unless you feel otherwise, I'd like to close this with a "Won't Implement"

-Sp is a hack...

But no, you can't really lock down the files with 600 permissions that I know of, considering every pacman operation (whether it uses them or not) loads the server list.

I might agree with the won't implement logic here.

OK, I'm fine with "Won't Fix" here.
With 600 permissions on /etc/pacman.d this indeed may be treated as a security hole, though Server can be setup in pacman.conf as well.
At the moment I'm using simple sed to change the generated -Sp output.

Well, 'are you root?' check probably could be done before trans_commit [it would be also a code-clearer to move "HDD manipulator" things behind _commit, and thus we would win some kind of --simulate option ;-]
Pro:
-user can play with not-modify-anything stuffs in libalpm
Contra:
-user get delayed 'operation not permitted' error

Nagy, how does this pertain to the -Sp issue? I don't follow

Ooops. I wrote this in the wrong thread (-Sp allowed only to root)

I want to write here this;-):
I don't understand you. Pacman doesn't operate at all, if it cannot read any of the config files (as Dan said), even the included ones (mirrorlist). So this hide password "feature" seems to be useless, because if pacman can read mirrorlist, then also user can.

Indeed, in this case that would be useful, if pacman didn't hang on "cannot include foo to pacman.conf", just give a warning. But you can see, that "if pacman can read mirrorlist, then also user can" still holds.

Correct. While pacman CURRENTLY hangs on that, it doesn't change my opinion on this feature.

How about this:
Allow 'Include' files to fail and continue, but ONLY on Include files
Output URLs with user@domain, but no password

Does this sound like a fair compromise?

It sounds like feature bloat to me. What good is a url without username@domain/password anyway, if one is needed?

I think we should not merge problems here. The bug at hand is a BUG- we produce invalid URLs with pacman -Sp output. That must be fixed for us to continue, and it has no bearing on whether the server was listed in pacman.conf or in an include file.

The feature request you are proposing should be filed seperately, something to the extent of "don't allow underprivileged users to have access to mirrorfiles with usernames and passwords". In that case, we still wouldn't filter usernames/passwords out of URLs, as that server would never even be shown if it is never read by the config loading code. If a user does run pacman as root, then they probably want a working URL.

I summarize my opinion again:
1. Aaron: filtering URLs (and anything from config file) is simply useless imho, because if you filter something, then this means that you _could_ read it, and if you could read it, then the current "uid" of pacman also can reach that "secret" information (by opening that config file by hand, or compile a patched pacman etc. etc.), so filtering of this content is simply needless (or at least a weak "protection")
2. Dan: I agree with you here, the Include problem is an other story (maybe this would worth an other task). I simply suggested that pacman shouldn't fail on include error, let me show an example:
Include = /etc/pacman.d/secret-mirrors (readable by root only)
Include = /etc/pacman.d/common-mirrors
By doing this, non-root users simply cannot see those mirrors (however, in most cases normal users needn't see any mirrors), and maybe there are some other secret informations where this would be useful (but probably not).

#2 is already on my working branch - it's a trivial change.
http://code.phraktured.net/?p=pacman.git;a=commitdiff;h=88206ddc117f6769f3396a79bc29ff8af10a2b49

Here's a patch which should fix this. I also threw in the port for good measure. alpm_db_get_url is only used in one place, so it shouldn't affect anything else.

Here's what the output looks like if no username and password is specified:
guest@mirror.cs.vt.edu/pub/ArchLinux/community/os/i686/xmms-1.2.11-1.pkg.tar.gz"> ftp://anonymous:libalpm@guest@mirror.cs.vt.edu/pub/ArchLinux/community/os/i686/xmms-1.2.11-1.pkg.tar.gz

Nice, that works. I'm just... ugh, I don't like it, but there's not much we can do about it if it's what people want. Whenever i see a "password" in a printf, I cringe.