Roadmap for version 3.4 Expand all | Collapse all
81% of 26 tasks completed. 5 open tasks:
- FS#5331 - Signed packages Expand Collapse
-
Hi!
I have noticed that the single most vulnerable point of archlinux (assuming you trust the developers) is that any mirror can be hacked and injected with various packages, and there would be virtually no way for an end user to notice this. As pacman would accept the local list of packages and the package downloaded/installed. And if someone noticed it it'd be too late either case.
This also means that users need to have some sort of trust to the mirror of their chosing. Many wouldn't even consider it probably. Others would trust their gut feeling. Or use the (almost terribly slow, for us sweedes) ftp.archlinux.org.
As I just set up my new public archlinux mirror it hit me that there is not any way that I can genuinly garuntee my users that my packages are safe and unmodified, more than users doing sample tests now and then. (If you need a pretty fast Swedish mirror, read at http://bbs.archlinux.org/viewtopic.php?t=24666 :)).
Signed packages would solve these problems. The signatures can be verified by a public key which the developers intergrate so any package going up for publishing will need a signature. The signatures can preferably be stored in the resperatory database file (current.db.tgz etc) and verified by pacman upon install.
If a user choose to trust other developers than the main they should be able to add their public keys to pacman's database aswell. pacman -Ka /home/data/key.pub, or smthing.
Now here comes the best part; the code is already fully developed :) Intergration with gnupg will assure this kind of verification to be easily in to place.
Hit me back with comments and/or suggestions.
- FS#12950 - Modifying package flags shouldn't require reinstallation Expand Collapse
-
To mark a package as installed as a dependency (or as explicitly installed), pacman requires to reinstall such package.
This shouldn't be needed, since sometimes reinstalling the package could be not possible and anyway it's an useless overhead.
- FS#14208 - Add a "--list" option or something similar for use with scripts. Expand Collapse
-
It would be useful to have an option in pacman (that doesn't require root) to display a complete list of packages to download for a given sync operation (with deps resolved unless --nodeps is given, etc), e.g.
pacman -Syu foo bar --list
would then print out a list of files to download, e.g.
kernel26 2.6.29.1-3
aria2 1.3.0-1
foo 3.5-3
bar 1.4-2
baz 3.5-1
Adding "--quiet" would remove the version from each line.
This shouldn't be difficult to implement considering that the "--print-uris" option already exists. "--print-uris" is not useful because it requires both root (why?*) and considerable parsing to extract the relevant info.
"--list" could be useful for remove operations as well as it could show all the packages that would be removed (cascades, etc).
I know that I would make ample use of this and I believe that others who develop tools for pacman would find it very useful as well. I also know the standard response is likely to be "submit a patch" but I still don't know C and this should be much easier for someone who's already familiar with the code (it should just be a tweak to "--print-uris"). Also, before someone says "just use alpm", well, I don't know C but beyond that, from what I've seen, the documentation for alpm is somewhere between chaos and limbo. I've even seen one of the devs say that it's still mostly a mystery to him, so it's hardly practical.
Anyway, this would be really useful. I really hope that one of the pacman devs agrees (please?).
* I've written a partial implementation of pacman in perl which does not require root to determine package downloads, so I don't understand why pacman needs it.
- FS#15657 - presence of new db version is not checked when <dbfile>.part exi Expand Collapse
-
Summary and Info:
When doing -Syy some time after previous download was interrupted:
:: Synchronizing package databases...
debug: using 'testing.db.tar.gz' for download progress
debug: existing file found, using it
debug: HTTP_PROXY: (null)
debug: http_proxy: (null)
debug: FTP_PROXY: (null)
debug: ftp_proxy: (null)
error: failed retrieving file 'testing.db.tar.gz' from
dev.archlinux.org : Requested Range Not Satisfiable
debug: failed to sync db: Requested Range Not Satisfiable
error: failed to update testing (Requested Range Not Satisfiable)
Between download was interrupted and new download started the db file was updated
and became smaller so that range does not exist anymore.
Not sure what would happen if range was satisfiable, theoretically it should result in a broken db file.
The bug here is that pacman does not seem to even check if the file was changed and goes straight to continuing the download of <dbname>.part
Steps to Reproduce:
you may want to try the attached file,
just put it in /var/lib/pacman and run -Syy
- FS#16630 - [pacman] bash completion Expand Collapse
-
Description:
In the function `_installed_pkgs()' in the file `/etc/bash_completion.d/pacman`, `ls' is used to get a list of packages for completion. On my machine (and many others I'm sure), ls is aliased to 'ls --color'. This results in the names of the packages including some color escape sequences, so that they don't complete properly. A possible remedy (and what I've done in the meantime) is just to change `ls' to `ls --color=never'.
This seems like a problem that might come up in other places as well, though I haven't bothered checking.
Additional info:
* package version(s)
3.3.2-1
Roadmap for version 4.0 Expand all | Collapse all
0% of 2 tasks completed. 2 open tasks:
- FS#8585 - Implement true transaction system in pacman Expand Collapse
-
Pacman needs a new transaction system that actually allows us to roll back package updates. This will solve a handful of issues we currently have, including several open bugs.
An initial proposal from Aaron:
I'm going to run with the hidden+suffix format here. That is:
/usr/bin/foo
will be extracted as
/usr/bin/.foo.pacman-new-$PID
on any error, it is deleted and all previous extractions are deleted.
Then, we move foo out of the way:
/usr/bin/foo --> /usr/bin/.foo.pacman-old-$PID
any error rolls back. Otherwise, move the new one in place
/usr/bin/.foo.pacman-new-$PID --> /usr/bin/foo
with obvious roll back.
So, in pseudo-code here:
new_files = []
old_files = []
try:
for file in package_files:
new_files += [extract(file.name + "-new-" + pid)]
if exists(file.name):
old_files += [move(file.name, file.name + "-old-" + pid)]
move_all(new_files, files)
except:
move_all(old_files, files)
delete_all(new_files)
else:
delete_all(old_files)
This should be small enough to performance test. Any problems here?
- FS#8586 - Implement tar database backend Expand Collapse
-
Everyone wants things sped up, so this is one possible approach that I think is worth it. We could easily download a db.tar.gz, inflate it but leave it tarred, and use it as our database. We would still have the benefits of the files approach, but gain a massive speed increase as we could load straight from the tar file into memory.
$ time tar cf local.db.tar local/
real 0m0.112s
user 0m0.023s
sys 0m0.087s
$ time tar xf local.db.tar
real 0m0.229s
user 0m0.010s
sys 0m0.210s
I'm not sure yet if I want to convert both the local and the sync DBs to the format. It makes a lot more sense to convert the sync DBs becuase they are read-only. In reality, the local DB and sync DB shouldn't have to be the same format, so this feature request is also a reminder to fix that issue.
Text Version