Merge lp:~mvo/aptdaemon/use-apt-auth.conf into lp:aptdaemon
Proposed by
Michael Vogt
on 2012-03-05
| Status: | Merged |
|---|---|
| Merged at revision: | 777 |
| Proposed branch: | lp:~mvo/aptdaemon/use-apt-auth.conf |
| Merge into: | lp:aptdaemon |
| Diff against target: |
112 lines (+61/-12) 2 files modified
aptdaemon/worker.py (+36/-12) tests/test_worker.py (+25/-0) |
| To merge this branch: | bzr merge lp:~mvo/aptdaemon/use-apt-auth.conf |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Michael Vogt | Resubmit on 2012-03-08 | ||
| Martin Pitt (community) | 2012-03-05 | Needs Fixing on 2012-03-08 | |
|
Review via email:
|
|||
Description of the Change
This branch moves all username/password data from a repository into /etc/apt/auth.conf
To post a comment you must log in.
lp:~mvo/aptdaemon/use-apt-auth.conf
updated
on 2012-03-06
- 779. By Michael Vogt on 2012-03-06
-
add a comment when credentials are moved
| Michael Vogt (mvo) wrote : | # |
Thanks for your review!
I fixed the issues you mentioned in r780.
review:
Resubmit
lp:~mvo/aptdaemon/use-apt-auth.conf
updated
on 2012-03-08
- 780. By Michael Vogt on 2012-03-08
-
fix review comments from Martin Pitt: a) typo fix b) do not chmod/chown but instead set umask c) check for exceptions in splituri()

nitpick:
> comment += " ;credentials put into /etc/apt/auth.conf"
This should be "; credentials ..."
> + res = urlsplit(uri)
Do we need to be concerned about exceptions here? or does the code already ensure that this is a valid URL? Is there any test case which runs that with an invalid URL, and one with a passwordless one?
Does netrc need any quoting if the password contains a space? I suppose that the URL is already encoded (i. e. %20), just making sure that this is handled.
58 + try: auth_conf_ path, uid, gid) auth_conf_ path, 0640)
59 + uid = gid = 0
60 + os.chown(
61 + os.chmod(
I think that's fine when creating the file. But I wouldn't change the permissions if it already exists; if the admin configures it to be writable for some sub-admin group we should respect that IMHO.
Seems ok to me otherwise.