Downloaded source files that you build and install should be verified to minimize security risks. Most AUR packages rely on checksums (and most of those are checksums generated by the maintainer when the package is updated, not provided by upstream). PGP signatures provide better security than checksums which is why support was added with the recent updates to the AUR website. Most packages still don't use them yet, either because upstream doesn't provide signed sources or because the maintainer simply hasn't updated to use them.
As for why you have to install the key instead of letting makepkg do it automatically, it provides a little more security. If the file had been intentionally corrupted, then it would be easy to sign it with the attacker's key and makepkg wouldn't even notice. As it is now, users who want security can carefully verify public keys before trusting them (or just run a simple command to import them without caring).
Btw, my key is in the Arch Linux keyring. Feel free to suggest on the pacman-dev list that makepkg first check with pacman-key before using the user's keyring ;)
Search Criteria
Package Details: mimeo 2017.6.6-1
| Git Clone URL: | https://aur.archlinux.org/mimeo.git (read-only) |
|---|---|
| Package Base: | mimeo |
| Description: | Open files by MIME-type or file name using regular expressions. |
| Upstream URL: | http://xyne.archlinux.ca/projects/mimeo |
| Keywords: | utilities |
| Licenses: | |
| Submitter: | Xyne |
| Maintainer: | Xyne |
| Last Packager: | Xyne |
| Votes: | 121 |
| Popularity: | 0.618881 |
| First Submitted: | 2009-12-16 02:54 |
| Last Updated: | 2017-06-06 22:40 |
Dependencies (4)
- file (file-git)
- python-xdg
- python3 (python30, python)
- MIME-types (mime-types) (optional) – for recognizing more MIME-types
Required by (3)
- obfilebrowser
- radio-france
- xdg-utils-mimeo (optional)
Sources (2)
Latest Comments
Xyne commented on 2017-09-09 15:20
Museb commented on 2017-09-09 09:50
==> Verifying source file signatures with gpg...
mimeo-2017.6.6.tar.xz ... FAILED (unknown public key 1D1F0DC78F173680)
==> ERROR: One or more PGP signatures could not be verified!
==> ERROR: Makepkg was unable to build mimeo.
sorry for being a noob but why does every other AUR-package install fine and for this one I have to go to the trouble of adding keys?
JP-Ellis commented on 2017-05-30 07:39
@Xyne Sorry I didn't see you replied. Python should always be installed to /usr/bin/python3 (at least on Arch Linux), so there is no harm in hard-coding this. This would also solve the issue encountered by @cswoodruff.
Virtual environments are actually fairly common, especially for people who need to have multiple versions of Python installed (or Python libraries). You probably haven't had people raise the issue because the fix is so simple... but I still think it would be better if mimeo ensured that the system installation of Python is used every time as opposed to explicitly using "whichever bash prefers" even if it isn't the one where the Mimeo library is installed.
cswoodruff commented on 2017-03-10 17:44
It would be good if the PKGBUILD could be changed so that it uses an explicit call to python3. This ensures that python3 is always used during the build process for people like me that have a link in their path overriding the default python (/home/user/bin/python --> /usr/bin/python2).
Xyne commented on 2017-01-29 12:41
@toketin
Looks like a temporary key server error. Try a different server or try again later.
toketin commented on 2017-01-22 21:07
$ gpg --recv-keys --keyserver hkp://pgp.mit.edu 1D1F0DC78F173680
gpg: ricezione dal keyserver fallita: Server indicated a failure
NuSkool commented on 2016-10-20 15:49
gpg --recv-keys --keyserver hkp://pgp.mit.edu 1D1F0DC78F173680
Xyne commented on 2016-09-07 21:04
@JP-Ellis
The issue of virtual environments has come up only once before in the last 4-5 years (iirc) so it seems to affect very few people. I wonder if just as many would be affected by hard-coded paths. Given that I currently neither use virtual environments nor mess around with paths, I have no strong opinion on the matter. Given that the launcher scripts are just minimalist wrappers around the Python executable, I'm more inclined to just leave it as-is and let the user's who bother to set up a virtual environment set up their own aliases or wrappers as well. I'm remain open to arguments.
JP-Ellis commented on 2016-08-28 12:03
It would be good if /usr/bin/mimeo could be changed so that it uses an absolute path for Python (that is, replace "python3" with "/usr/bin/python3"). This ensures that the system python is always used and the mimeo module is available. This is an issue for people who use python virtual environments as the system modules are (generally) not made available in the virtual environment.
zoopp commented on 2016-01-25 19:13
I'm experiencing a weird issue in which mimeo launches two applications when I want to open certain files.
For example,
┌─┤21:07:19│zoopp@zoopp-laptop:~
└──────────╼ mimeo --debug ~/wallhaven-317663.jpg
DEBUG: loading arguments from /home/zoopp/.config/mimeo/default_arguments.txt
DEBUG: opening /home/zoopp/.config/mimeo/associations.txt
DEBUG: ['/usr/bin/eog', '/home/zoopp/wallhaven-317663.jpg']
DEBUG: ['gimp-2.8', 'file:///home/zoopp/wallhaven-317663.jpg']
I've noticed that this happens only for files which have associations in ~/.config/mimeo/associations.txt. For reference, these are the file contents: https://paste.kde.org/po6wbvc9i.
I'm thinking of taking a look into it when I'll get some time. In the meantime, might someone have any ideas what could be wrong?