Re: [new] sysutils/vifm
On 2022/08/27 15:34, xaizek wrote: > On Sat, Aug 27, 2022 at 03:08:09PM +0100, Stuart Henderson wrote: > > I think it makes sense to add it back. > > Great. > > > Comments on the port: > > - we don't use subpackages just for desktop files and dependencies > > Something in manpages/guide made me think otherwise, but I can't find it > now. Dropped that part. > > > - there are some checks in configure for various tools (groff, vim, git) - > > everything from packages that affects the build needs to be listed as a > > dependency or disabled (e.g. for groff/mandoc the right way is probably > > to set MANGEN_PROG=mandoc, for vim it looks like maybe nothing is needed > > because unless I missed something perl is used in preference, and perl > > is always available in base) > > MANGEN_PROG=mandoc works and ignores installed groff. > > Yes, Vim is used to generate tags only if perl isn't available. > > Git is used to get tag & commit revision if build happens inside of a > repository. If there is no .git directory, presence of git makes no > difference. > > Other standard tools (awk, sed, col) are used to process output of > groff/mandoc if they are available. Thanks. I've readded it with small tweaks; - add the pixmap/desktop file entries to pkg/PLIST with @comment, so that future regen's won't pick them up - drop TEST_DEPENDS, it's implied by USE_GMAKE
Re: [new] sysutils/vifm
On Sat, Aug 27, 2022 at 03:08:09PM +0100, Stuart Henderson wrote: > I think it makes sense to add it back. Great. > Comments on the port: > - we don't use subpackages just for desktop files and dependencies Something in manpages/guide made me think otherwise, but I can't find it now. Dropped that part. > - there are some checks in configure for various tools (groff, vim, git) - > everything from packages that affects the build needs to be listed as a > dependency or disabled (e.g. for groff/mandoc the right way is probably > to set MANGEN_PROG=mandoc, for vim it looks like maybe nothing is needed > because unless I missed something perl is used in preference, and perl > is always available in base) MANGEN_PROG=mandoc works and ignores installed groff. Yes, Vim is used to generate tags only if perl isn't available. Git is used to get tag & commit revision if build happens inside of a repository. If there is no .git directory, presence of git makes no difference. Other standard tools (awk, sed, col) are used to process output of groff/mandoc if they are available. > On 2022/08/27 11:13, xaizek wrote: > > Hello, > > > > As far as I know port for Vifm was included once, got removed and then > > there was one failed attempt to add it back. There seems to be some > > interest in having it, and in particular I've received a request for a > > port as Vifm's maintainer, so I decided to give it a try after using > > OpenBSD for a bit for other reasons. > > > > I originally declined making a port because I'm not using OpenBSD, > > but I can run it in a VM for tests and filter out all emails from this > > list that don't mention "vifm" to keep an eye on the port. Although > > ideally, if this gets accepted, some OpenBSD & Vifm user could take over > > the port and just ask me for assistance in case of issues. > > > > This is a multi-package port. -main doesn't depend on any other port, > > except during build. -desktop provides .desktop file with a > > corresponding pixmap and depends on devel/desktop-file-utils. Tests > > pass. /etc is handled via @sample. There is a number of patches, but > > they should all be gone for the next release. > > > > pkg/DESCR-main: > > > > Vifm is a file manager with curses interface, which provides Vim-like > > environment for managing objects within file systems, extended with some > > useful ideas from mutt. If you use vi, Vifm gives you complete keyboard > > control over your files without having to learn a new set of commands. > > > > Install vifm-desktop pakcage for desktop integration. > > > > pkg/DESCR-desktop: > > > > This package adds .desktop-file of Vifm. > > > > Best regards, > > xaizek sysutils.tar.bz2 Description: Binary data
Re: [new] sysutils/vifm
I think it makes sense to add it back. Comments on the port: - we don't use subpackages just for desktop files and dependencies - there are some checks in configure for various tools (groff, vim, git) - everything from packages that affects the build needs to be listed as a dependency or disabled (e.g. for groff/mandoc the right way is probably to set MANGEN_PROG=mandoc, for vim it looks like maybe nothing is needed because unless I missed something perl is used in preference, and perl is always available in base) On 2022/08/27 11:13, xaizek wrote: > Hello, > > As far as I know port for Vifm was included once, got removed and then > there was one failed attempt to add it back. There seems to be some > interest in having it, and in particular I've received a request for a > port as Vifm's maintainer, so I decided to give it a try after using > OpenBSD for a bit for other reasons. > > I originally declined making a port because I'm not using OpenBSD, > but I can run it in a VM for tests and filter out all emails from this > list that don't mention "vifm" to keep an eye on the port. Although > ideally, if this gets accepted, some OpenBSD & Vifm user could take over > the port and just ask me for assistance in case of issues. > > This is a multi-package port. -main doesn't depend on any other port, > except during build. -desktop provides .desktop file with a > corresponding pixmap and depends on devel/desktop-file-utils. Tests > pass. /etc is handled via @sample. There is a number of patches, but > they should all be gone for the next release. > > pkg/DESCR-main: > > Vifm is a file manager with curses interface, which provides Vim-like > environment for managing objects within file systems, extended with some > useful ideas from mutt. If you use vi, Vifm gives you complete keyboard > control over your files without having to learn a new set of commands. > > Install vifm-desktop pakcage for desktop integration. > > pkg/DESCR-desktop: > > This package adds .desktop-file of Vifm. > > Best regards, > xaizek
Re: NEW: sysutils/vifm
BTW, if anyone plans on committing vifm, be aware that there's a quirks entry from when it was last in the tree, and you will probably want to do 'cvs add's rather than 'cvs import' to avoid having to deal with merge conflicts.
Re: NEW: sysutils/vifm
Dmitrij D. Czarkoff said: > Here is a tarball with another attempt at vifm port: > > - uses waitpid(2) to reap spawned processes > - in mime detection code uses pledge(2) + libmagic(3) as first choice >and execl(3) + file(1) as second > - same in filetype detection (in previous ports was just popen(3)) > - does nothing to one remaining popen(3) and multiple system(3) calls. > - gets rid of FLAVORs > > If someone wants to replace remaining popen(3) and system(3), useful > egrep pattern is "(os|vifm)_system". I have better things to do. > > Please, don't mistake this message for implicit OK. A couple of bug fixes... -- Dmitrij D. Czarkoff vifm-0.8.1a.tgz Description: application/tar-gz
Re: NEW: sysutils/vifm
Stuart Henderson said:
> > - in mime detection code uses pledge(2) + libmagic(3) as first choice
> >and execl(3) + file(1) as second
>
> er, we were trying to get rid of libmagic use...
As I see it, we are trying to solve security issues related to the fact
that libmagic may be tricked into executing code from inspected file.
The solution, as discussed earlier, was to use file(1) with its own
parser of magic database. That said, it was observed that libmagic
gives better results then our file(1) with our magic database. Thus
previous approach was to split the ports into two flavors: secure
(file(1) only) and usable (libmagic).
This diff puts libmagic-interfacing code into subprocess with
pledge("stdio rpath"), so that libmagic can't harm user in meaningful
way. If it tries to do something funny, it gets killed, and
execl("/usr/bin/file", ...) is used instead. I think this way users are
served better then with either of ports above.
--
Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On 2016/06/12 11:03, Dmitrij D. Czarkoff wrote: > Here is a tarball with another attempt at vifm port: > > - uses waitpid(2) to reap spawned processes > - in mime detection code uses pledge(2) + libmagic(3) as first choice >and execl(3) + file(1) as second er, we were trying to get rid of libmagic use... > - same in filetype detection (in previous ports was just popen(3)) > - does nothing to one remaining popen(3) and multiple system(3) calls. > - gets rid of FLAVORs > > If someone wants to replace remaining popen(3) and system(3), useful > egrep pattern is "(os|vifm)_system". I have better things to do. > > Please, don't mistake this message for implicit OK. > > -- > Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
Here is a tarball with another attempt at vifm port: - uses waitpid(2) to reap spawned processes - in mime detection code uses pledge(2) + libmagic(3) as first choice and execl(3) + file(1) as second - same in filetype detection (in previous ports was just popen(3)) - does nothing to one remaining popen(3) and multiple system(3) calls. - gets rid of FLAVORs If someone wants to replace remaining popen(3) and system(3), useful egrep pattern is "(os|vifm)_system". I have better things to do. Please, don't mistake this message for implicit OK. -- Dmitrij D. Czarkoff vifm-0.8.1a.tgz Description: application/tar-gz
Re: NEW: sysutils/vifm
Rafael Sadowski said:
> here is a third and last try to push vifm in ports tree.
Now that we have pledge(2), it would probably be a better idea to use
libmagic with fork+pledge.
| + /* replace single quotes with double */
| + if (strchr(filename, '\''))
| {
| - return -1;
| + qp = quoted_filename;
| +
| + do {
| + if (*filename == '\'')
| + *qp++ = '\\';
| + *qp++ = *filename;
| + } while (*filename++ != '\0');
| +
| + filename = quoted_filename;
| }
This is not needed. And even if it was, comment should have been
different.
| + switch (fork())
| {
| - pclose(pipe);
| - return -1;
| + case -1:
| + printf("ERROR: forking child process failed\n");
| + return -1;
| + case 0:
| + dup2 (pipes[1], STDOUT_FILENO);
| + close(pipes[0]);
| + close(pipes[1]);
| + /* Use the file command to get mimetype */
| + execl("/usr/bin/file", "file", "-b", "--mime-type",
filename);
| + exit(0);
| + default:
| + close(pipes[1]);
| + (void)read(pipes[0], buf, buf_sz);
Shouldn't the parent process wait(2) for child?
--
Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On 2016/06/09 20:39, Landry Breuil wrote: > So, fwiw, the attached version is ok for me to import - stuff can still > be fixed in-tree if more issues arise. Let's stop the bikeshedding, and > thank Rafael for his perseverance. Kill the patch.orig and OK with me. Though the desktop-file-utils dep for no_x11 is pretty horrible, I think that should be made conditional and move the @exec to a PFRAG, but that could be done after it's in..
Re: NEW: sysutils/vifm
On Wed, Jun 08, 2016 at 11:00:21PM +0200, Rafael Sadowski wrote: > On Wed Jun 08, 2016 at 09:34:50PM +0200, Landry Breuil wrote: > > On Tue, Jun 07, 2016 at 09:28:37PM +0200, Rafael Sadowski wrote: > > > Hi ports@ and vifm friends, > > > > > > here is a third and last try to push vifm in ports tree. > > > > > > port core features: > > > - The same as: http://marc.info/?l=openbsd-ports=145647165914163=2 > > > - new: remove popen(2) call and replace with fork(2)(execl(3) > > > > > > pkg/DESCR: > > > > > > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > > > vifm gives you complete keyboard control over your files without having > > > to learn a new set of commands. It goes not just about vi[m] like > > > keybindings, but also about modes, options, registers, commands and > > > other things you might already like in vi[m]. > > > > > > OK, Comments? > > > > Has all the failure/risky cases that were reported in the last thread > > tested/taken care of now ? > > > > Landry > > Of course, I fixed all failure/risky cases and yes I tested it well. I > would have thought that was patently obvious. I'll send fork/execl > replacement patch upstream. Here's a slightly modified version of your patch to fix warnings: /usr/obj/tmpfs/ports/vifm-0.8.1a/vifm-0.8.1a/src/int/file_magic.c:181: warning: missing sentinel in function call /usr/obj/tmpfs/ports/vifm-0.8.1a/vifm-0.8.1a/src/int/file_magic.c:182: warning: implicit declaration of function 'exit' /usr/obj/tmpfs/ports/vifm-0.8.1a/vifm-0.8.1a/src/int/file_magic.c:182: warning: incompatible implicit declaration of built-in function 'exit' - include stdlib.h for exit() - remove unused char command declaration - add NULL sentinel as last arg of execl() I've tested it a bit, with a file named "echo 'foo' > bar" in /tmp, no ill effect. But that was with the default gtk backend, and it allows me to open the file in mousepad fine. With the no_x11 FLAVOR, it 'does the right thing' afaict. 30832 vifm ARGS [0] = "file" [1] = "-b" [2] = "--mime-type" [3] = "/tmp/echo \\'foo\\' > bar" And via enter, opens the file in vim. 61442 vifm ARGS [0] = "/bin/ksh" [1] = "-c" [2] = "vim /tmp/echo\\ \\'foo\\'\\ \\>\\ bar" 66333 ksh ARGS [0] = "vim" [1] = "/tmp/echo 'foo' > bar" Tested slightly with jpg and mp4 files, mimetype seems correctly found, i still have 'less' options to open the file than with the default flavor (check :f) but that's expected. So, fwiw, the attached version is ok for me to import - stuff can still be fixed in-tree if more issues arise. Let's stop the bikeshedding, and thank Rafael for his perseverance. Landry vifm2.tgz Description: application/tar-gz
Re: NEW: sysutils/vifm
On Wed Jun 08, 2016 at 09:34:50PM +0200, Landry Breuil wrote: > On Tue, Jun 07, 2016 at 09:28:37PM +0200, Rafael Sadowski wrote: > > Hi ports@ and vifm friends, > > > > here is a third and last try to push vifm in ports tree. > > > > port core features: > > - The same as: http://marc.info/?l=openbsd-ports=145647165914163=2 > > - new: remove popen(2) call and replace with fork(2)(execl(3) > > > > pkg/DESCR: > > > > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > > vifm gives you complete keyboard control over your files without having > > to learn a new set of commands. It goes not just about vi[m] like > > keybindings, but also about modes, options, registers, commands and > > other things you might already like in vi[m]. > > > > OK, Comments? > > Has all the failure/risky cases that were reported in the last thread > tested/taken care of now ? > > Landry Of course, I fixed all failure/risky cases and yes I tested it well. I would have thought that was patently obvious. I'll send fork/execl replacement patch upstream. Rafael
Re: NEW: sysutils/vifm
On Tue, Jun 07, 2016 at 09:28:37PM +0200, Rafael Sadowski wrote: > Hi ports@ and vifm friends, > > here is a third and last try to push vifm in ports tree. > > port core features: > - The same as: http://marc.info/?l=openbsd-ports=145647165914163=2 > - new: remove popen(2) call and replace with fork(2)(execl(3) > > pkg/DESCR: > > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > vifm gives you complete keyboard control over your files without having > to learn a new set of commands. It goes not just about vi[m] like > keybindings, but also about modes, options, registers, commands and > other things you might already like in vi[m]. > > OK, Comments? Has all the failure/risky cases that were reported in the last thread tested/taken care of now ? Landry
Re: NEW: sysutils/vifm
Am 07.06.2016 21:28:37, schrieb Rafael Sadowski: > Hi ports@ and vifm friends, > > here is a third and last try to push vifm in ports tree. > > port core features: > - The same as: > http://marc.info/?l=openbsd-ports=145647165914163=2 > - new: remove popen(2) call and replace with fork(2)(execl(3) > > pkg/DESCR: > > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > vifm gives you complete keyboard control over your files without having > to learn a new set of commands. It goes not just about vi[m] like > keybindings, but also about modes, options, registers, commands and > other things you might already like in vi[m]. > > OK, Comments? > > Best regards, > > Rafael Dear Rafael, I'd like to see it in the ports tree. Many thanks and regards. Uwe
Re: NEW: sysutils/vifm
Rafael Sadowski said:
> - czarkoff@'s file(1)-based mime type detection patch.
My patch was actually bad. It does not fix vulnerability it is supposed
to fix.
| + if (strchr(filename, '\''))
| + {
| + qp = quoted_filename;
| +
| + do {
| + if (*filename == '\'')
| + *qp++ = '\\';
| + *qp++ = *filename;
| + } while (*filename++ != '\0');
| +
| + filename = quoted_filename;
| + }
| +
For some reason I thought that backslash-escaping single quotes inside
single-quoted string in shell will help. It won't. Eg. filename
'$(rm -R ~)
will cause all the due damage.
The quoting part can be improved to replace every single quote with
'\"'
but I am not sure whether it will solve all the problems. It would make
most sense to switching code from popen(3) to fork(2)+exec(3) instead.
> - add "no_x11" flavor (from czarkoff@).
> -- no_x11 flavor comes with 3 wantlibs ;)
Once "file" backend is fixed, there would be no need in flavors any more
I believe.
--
Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On Fri Feb 26, 2016 at 08:26:47AM +0100, Rafael Sadowski wrote: > hey @ports and vifm friends, > > here is a second try to push vifm in ports tree. > > port core features: > > - default build without libmagic > - czarkoff@'s file(1)-based mime type detection patch. > -- I'll pull request upstream with czarkoff's okay. > - add "no_x11" flavor (from czarkoff@). > -- no_x11 flavor comes with 3 wantlibs ;) > - 0.8.1a update. > > tested @amd64. Many thanks to czarkoff from some good advice. > > pkg/DESCR: > > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > vifm gives you complete keyboard control over your files without having > to learn a new set of commands. It goes not just about vi[m] like > keybindings, but also about modes, options, registers, commands and other > things you might already like in vi[m]. > > Best regards, > > Rafael *ping* >From no one okay after the wild discussion[1]? [1]: https://marc.info/?l=openbsd-ports=145400156405000=2
Re: NEW: sysutils/vifm
Landry Breuil said: > On Wed, Feb 03, 2016 at 12:42:34AM +0100, Dmitrij D. Czarkoff wrote: > > Stuart Henderson said: > > > On 2016/02/03 00:25, Dmitrij D. Czarkoff wrote: > > > > Stuart Henderson said: > > > > > On 2016/02/02 21:58, Landry Breuil wrote: > > > > > > Oh, and the code in src/int/file_magic.c even has a fallback to use > > > > > > file > > > > > > %s -b --mime-type called via popen().. > > > > > > > > > > It would be nice to kill the other options and use file(1) from base > > > > > as the only detection method, it is *loads* safer. > > > > > > > > Well, the actual code is: > > > > > > > > | snprintf(command, sizeof(command), "file \"%s\" -b --mime-type", > > > > filename); > > > > > > > > Note double quotes. Of course no quoting is performed on filename. > > > > Thus: > > > > > > > > 1. If filename contains double quote, vifm sigfaults. > > > > 2. If filename is nasty, nasty things happen. Eg. I renamed a png image > > > >to "$(echo text)", and vifm opened it in vi. I guess filename > > > >"`doas rm -Rf $HOME/*`" will also pleasantly surprise user. > > > > > > Ugh. I have seen CVEs assigned for smaller problems than that! > > > > I've added a naive patch to openbsd-wip version of this port. Vifm > > still opens renamed png in vi, but at least does not execute commands. > > better report it directly upstream then ? :) I'd leave this honor to maintainer. -- Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 05:09:34PM +0100, Tobias Ulmer wrote: > What's the point when it requires half of GNOME? You should call the > package gvifm... > > CONFIGURE_ARGS += --without-gtk --without-libmagic --without-X11 > --without-dyn-X11 As the one who originally ported vifm years ago, its code quality was not great, and at some point it got removed. Apparently upstream has now revived this software, has a new website, so why not giving it a chance again, especially if people seem to like it ? I've tested it briefly on macppc and it seemd to work. The gtk+2/libmagic/libX11 dependency, maybe it is a bit overkill (from configure.ac): [use GTK+ to determine mimetypes if available @<:@default=yes@:>@]), [use libmagic to determine mimetypes if available @<:@default=yes@:>@]), [use libX11 to determine terminal emulator title @<:@default=yes@:>@]),. [load libX11 dynamically @<:@default=yes@:>@]) @rafael: if you decide to keep gtk dependency, LIB_DEPENDS=x11/gtk+2 ought to be enough, no need to list pango/glib/atk/gdk_pxibuf. You didnt set CONFIGURE_ARGS so x11/libmagic will be picked up automatically if present at configure time. This will be an issue in bulks. > (libmagic is a security disaster waiting to happen in a file manager) sqlite> select distinct(fullpkgpath) from depends where dependspath like '%libmagic%'; audio/sox devel/py-libmagic devel/py-libmagic,python3 editors/tpad geo/viking graphics/qiv lang/classpath mail/amavisd-new,-main mail/zarafa/zarafa,-main misc/p5-File-LibMagic multimedia/mediatomb multimedia/mkvtoolnix multimedia/mkvtoolnix,no_x11 net/bro net/mldonkey net/nepenthes print/lyx security/yara/main sysutils/binwalk textproc/zathura/core www/xapian-omega x11/emelfm2 x11/gnome/file-roller Then i guess we have other issues here. Landry
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 08:56:35PM +0100, Rafael Sadowski wrote: > On Tue Feb 02, 2016 at 05:09:34PM +0100, Tobias Ulmer wrote: > > What's the point when it requires half of GNOME? You should call the > > package gvifm... > > Is that my fault!? If you don't like, it don't use it. I'm NOT a vifm > developer. I only port for my friend Uwe. That's it! > > > > > CONFIGURE_ARGS += --without-gtk --without-libmagic --without-X11 > > --without-dyn-X11 > > That's not my line. I think that was a suggestion from tobias :) > > > > (libmagic is a security disaster waiting to happen in a file manager) > > I follow you but it's just a port and not base stuff. I see misc/screen > in the ports tree. In my opinion screen is creep but it's only my > personal opinion. > > Finale, Dmitrij D. Czarkoff starts a "no_x11" flavor. Thanks Dmitrij. > https://github.com/jasperla/openbsd-wip/commit/a755a173f7ff05c23ab6d999716a4fe4855a54bc Im not sure 'feature-set-wise' that it's worth adding the complexity of a FLAVOR. You're the maintainer, you decide, but since libmagic and gtk+2 are here for the same feature (mimetype checking) maybe have a look at the code and see how it works (fine or not). Either way, please explicitely list --with/--without in CONFIGURE_ARGS for clarity. Note that the dyn-x11 thing was apparently broken in github, they added the requirement for -ldl which doesnt make sense on OpenBSD. So please check that the feature actually works if you want to enable it Landry >
Re: NEW: sysutils/vifm
On Tue Feb 02, 2016 at 05:09:34PM +0100, Tobias Ulmer wrote: > What's the point when it requires half of GNOME? You should call the > package gvifm... Is that my fault!? If you don't like, it don't use it. I'm NOT a vifm developer. I only port for my friend Uwe. That's it! > > CONFIGURE_ARGS += --without-gtk --without-libmagic --without-X11 > --without-dyn-X11 That's not my line. > > (libmagic is a security disaster waiting to happen in a file manager) I follow you but it's just a port and not base stuff. I see misc/screen in the ports tree. In my opinion screen is creep but it's only my personal opinion. Finale, Dmitrij D. Czarkoff starts a "no_x11" flavor. Thanks Dmitrij. https://github.com/jasperla/openbsd-wip/commit/a755a173f7ff05c23ab6d999716a4fe4855a54bc Best regards, Rafael
Re: NEW: sysutils/vifm
Landry Breuil said: > Im not sure 'feature-set-wise' that it's worth adding the complexity of > a FLAVOR. Flavors were supposed to address the "half GNOME" issue. -- Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 09:34:13PM +0100, Dmitrij D. Czarkoff wrote: > Landry Breuil said: > > Im not sure 'feature-set-wise' that it's worth adding the complexity of > > a FLAVOR. > > Flavors were supposed to address the "half GNOME" issue. Sure, but in that particular case it turned into 'do you want your mime detection to be done with gtk+ (bo gnome blooaaat) or with libmagic (bo full of security issues)' :) Honestly, try both implementations, figure out which one 'performs' better in termes of filetype detection, and choose the less worst :) or just disable the feature if it not used much/broken. Doing a FLAVOR for this is just overkill, as 99% of the users wont know which one to choose (shall we build both by default?), and expect a non-no_x11 flavor to have some kind of GUI.. Landry
Re: NEW: sysutils/vifm
> On Tue, Feb 02, 2016 at 05:09:34PM +0100, Tobias Ulmer wrote:
> > (libmagic is a security disaster waiting to happen in a file manager)
>
On 2016/02/02 19:22, Landry Breuil wrote:
> sqlite> select distinct(fullpkgpath) from depends where dependspath like
> '%libmagic%';
[..]
> mail/amavisd-new,-main
Possible diff for amavisd-new below, I'm running it here, needs a bunch
more testing though.
> Then i guess we have other issues here.
Yep, it takes time to chip away at them.
Index: Makefile
===
RCS file: /cvs/ports/mail/amavisd-new/Makefile,v
retrieving revision 1.40
diff -u -p -r1.40 Makefile
--- Makefile15 Jul 2015 19:26:44 - 1.40
+++ Makefile2 Feb 2016 22:08:55 -
@@ -9,7 +9,7 @@ PKGNAME-main= ${DISTNAME}
PKGNAME-utils= amavisd-new-utils-${V}
CATEGORIES=mail security
-REVISION-main= 2
+REVISION-main= 3
REVISION-utils=2
HOMEPAGE= http://www.amavis.org/
Index: patches/patch-amavisd
===
RCS file: /cvs/ports/mail/amavisd-new/patches/patch-amavisd,v
retrieving revision 1.12
diff -u -p -r1.12 patch-amavisd
--- patches/patch-amavisd 2 Feb 2016 21:58:32 - 1.12
+++ patches/patch-amavisd 2 Feb 2016 22:08:55 -
@@ -1,6 +1,18 @@
$OpenBSD: patch-amavisd,v 1.12 2016/02/02 21:58:32 sthen Exp $
+
+Hunks 1, 3: Disable File::LibMagic in favour of safer file(1) from base.
+
--- amavisd.orig Sun Oct 26 00:06:00 2014
-+++ amavisdTue Feb 2 21:57:58 2016
amavisdTue Feb 2 22:08:33 2016
+@@ -12557,7 +12557,7 @@ sub after_chroot_init() {
+grep(/\.pm\z/, keys %INC)) {
+ next if !grep($_ eq $m, qw(Amavis::Conf
+ Archive::Tar Archive::Zip Compress::Zlib Compress::Raw::Zlib
+- Convert::TNEF Convert::UUlib File::LibMagic
++ Convert::TNEF Convert::UUlib
+ MIME::Entity MIME::Parser MIME::Tools Mail::Header Mail::Internet
+ Digest::MD5 Digest::SHA Digest::SHA1 Crypt::OpenSSL::RSA
+ Authen::SASL Authen::SASL::XS Authen::SASL::Cyrus Authen::SASL::Perl
@@ -29847,7 +29847,7 @@ sub new_SpamAssassin_instance {
# PREFIX=> '/usr/local',
# DEF_RULES_DIR => '/usr/local/share/spamassassin',
@@ -10,3 +22,21 @@ $OpenBSD: patch-amavisd,v 1.12 2016/02/0
#see Mail::SpamAssassin man page for other options
};
if ($sa_version_num < 3.001005 && !defined $sa_args->{LOCAL_STATE_DIR})
+@@ -30595,17 +30595,8 @@ BEGIN {
+ import Amavis::Unpackers::NewFilename qw(consumed_bytes);
+ }
+
+-BEGIN {
+ use vars qw($filemagic);
+- eval {
+-require File::LibMagic;
+-File::LibMagic->VERSION(1.00);
+-import File::LibMagic;
+-$filemagic = File::LibMagic->new;
+- } or do {
+ undef $filemagic;
+- };
+-}
+
+ use subs @EXPORT_OK;
+
Re: NEW: sysutils/vifm
Landry Breuil said:
> Doing a FLAVOR for this is just overkill, as 99% of the users wont know
> which one to choose (shall we build both by default?),
Idea is that people should install package with no FLAVOR. If they
really, really want to have as little dependencies as possible, they
install "no_x11" FLAVORed package.
> and expect a non-no_x11 flavor to have some kind of GUI..
Let them. Really, X11 does not mean GUI.
> Oh, and the code in src/int/file_magic.c even has a fallback to use file
> %s -b --mime-type called via popen()..
>
> In terms of priority:
> ---
> if(get_gtk_mimetype(file, mimetype) == -1)
> {
> if(get_magic_mimetype(file, mimetype) == -1)
> {
> if(get_file_mimetype(file, mimetype, sizeof(mimetype)) == -1)
> return NULL;
> }
> }
> ---
>
> So by default the primary method is gtk, then magic, then file.
Maybe file is not a bad option - in the end it is the most secure
filetype detection tool we have in OpenBSD ATM.
> And if i still look at the code... one of the uses of getting the
> mimetype of a file seems to be.. to print the mimetype. Another (grep -r
> get_handlers) seems to be to propose the various mimetype handlers found
> in the desktop files to handle it. am i reading this right ?
Well, I don't use file managers, but I suppose that printing mimetype
and automagically open files in right application is why you may want a
file managers. Otherwise cp, rm, ln and cd are your file manager.
--
Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 08:56:35PM +0100, Rafael Sadowski wrote: > On Tue Feb 02, 2016 at 05:09:34PM +0100, Tobias Ulmer wrote: > > What's the point when it requires half of GNOME? You should call the > > package gvifm... > > Is that my fault!? If you don't like, it don't use it. I'm NOT a vifm > developer. I only port for my friend Uwe. That's it! Take a chill pill, dude. I find it hilarious (and a little disgusting) a ncurses based file manager now depends on gtk. > > > > > CONFIGURE_ARGS += --without-gtk --without-libmagic --without-X11 > > --without-dyn-X11 > > That's not my line. Indeed, that's was my mild suggestion/attempt at decreasing the bloat. I've tried it like this on sparc64 and it worked fine. > > > > > > (libmagic is a security disaster waiting to happen in a file manager) > > I follow you but it's just a port and not base stuff. I see misc/screen > in the ports tree. In my opinion screen is creep but it's only my > personal opinion. > > Finale, Dmitrij D. Czarkoff starts a "no_x11" flavor. Thanks Dmitrij. > https://github.com/jasperla/openbsd-wip/commit/a755a173f7ff05c23ab6d999716a4fe4855a54bc Good idea, I like it. > > Best regards, > > Rafael
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 10:41:12PM +0100, Rafael Sadowski wrote: > Yes, if we disable GTK+ and libmagic we fallback to file(1). Easy choice. Just use file(1) and disable the others. file(1) is satisfied by the base install (no extra deps) and is also the most secure option of the bunch.
Re: NEW: sysutils/vifm
On 2016/02/02 21:58, Landry Breuil wrote: > Oh, and the code in src/int/file_magic.c even has a fallback to use file > %s -b --mime-type called via popen().. It would be nice to kill the other options and use file(1) from base as the only detection method, it is *loads* safer.
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 09:44:52PM +0100, Landry Breuil wrote:
> On Tue, Feb 02, 2016 at 09:34:13PM +0100, Dmitrij D. Czarkoff wrote:
> > Landry Breuil said:
> > > Im not sure 'feature-set-wise' that it's worth adding the complexity of
> > > a FLAVOR.
> >
> > Flavors were supposed to address the "half GNOME" issue.
>
> Sure, but in that particular case it turned into 'do you want your mime
> detection to be done with gtk+ (bo gnome blooaaat) or with libmagic
> (bo full of security issues)' :)
>
> Honestly, try both implementations, figure out which one 'performs'
> better in termes of filetype detection, and choose the less worst :) or
> just disable the feature if it not used much/broken.
>
> Doing a FLAVOR for this is just overkill, as 99% of the users wont know
> which one to choose (shall we build both by default?), and expect a
> non-no_x11 flavor to have some kind of GUI..
Oh, and the code in src/int/file_magic.c even has a fallback to use file
%s -b --mime-type called via popen()..
In terms of priority:
---
if(get_gtk_mimetype(file, mimetype) == -1)
{
if(get_magic_mimetype(file, mimetype) == -1)
{
if(get_file_mimetype(file, mimetype, sizeof(mimetype)) == -1)
return NULL;
}
}
---
So by default the primary method is gtk, then magic, then file.
And if i still look at the code... one of the uses of getting the
mimetype of a file seems to be.. to print the mimetype. Another (grep -r
get_handlers) seems to be to propose the various mimetype handlers found
in the desktop files to handle it. am i reading this right ?
Oh well.
Landry
Re: NEW: sysutils/vifm
On Tue Feb 02, 2016 at 10:16:47PM +0100, Dmitrij D. Czarkoff wrote:
> Landry Breuil said:
> > Doing a FLAVOR for this is just overkill, as 99% of the users wont know
> > which one to choose (shall we build both by default?),
>
> Idea is that people should install package with no FLAVOR. If they
> really, really want to have as little dependencies as possible, they
> install "no_x11" FLAVORed package.
>
> > and expect a non-no_x11 flavor to have some kind of GUI..
>
> Let them. Really, X11 does not mean GUI.
I like the flavor idea from Dmitrij. It feels right. Tobias tried it on
sparc64 (Not the flavor but some flags).
So let's try with flavor. Dmitrij has begun so let's (maybe) improve and
test at daily work.
>
> > Oh, and the code in src/int/file_magic.c even has a fallback to use file
> > %s -b --mime-type called via popen()..
> >
> > In terms of priority:
> > ---
> > if(get_gtk_mimetype(file, mimetype) == -1)
> > {
> > if(get_magic_mimetype(file, mimetype) == -1)
> > {
> > if(get_file_mimetype(file, mimetype, sizeof(mimetype)) == -1)
> > return NULL;
> > }
> > }
> > ---
> >
> > So by default the primary method is gtk, then magic, then file.
>
> Maybe file is not a bad option - in the end it is the most secure
> filetype detection tool we have in OpenBSD ATM.
>
> > And if i still look at the code... one of the uses of getting the
> > mimetype of a file seems to be.. to print the mimetype. Another (grep -r
> > get_handlers) seems to be to propose the various mimetype handlers found
> > in the desktop files to handle it. am i reading this right ?
>
> Well, I don't use file managers, but I suppose that printing mimetype
> and automagically open files in right application is why you may want a
> file managers. Otherwise cp, rm, ln and cd are your file manager.
>
Yes, if we disable GTK+ and libmagic we fallback to file(1).
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 10:52:45PM +0100, Stefan Sperling wrote: > On Tue, Feb 02, 2016 at 10:41:12PM +0100, Rafael Sadowski wrote: > > Yes, if we disable GTK+ and libmagic we fallback to file(1). > > Easy choice. Just use file(1) and disable the others. file(1) is satisfied > by the base install (no extra deps) and is also the most secure option of > the bunch. Tried with just the file backend enabled, it's "less" rich than the gtk/libmagic combination but works for pdf/jpg/txt/mp3. No match for tgz, proposes fuse-archivemount for .tar.gz, proposes text editor for gpx/gsb... for the latter, the correct mimetype was found and the best handler was proposed. I guess that's what you get for using file from base which is ... basic. (try :f on a file to see the available handlers for the detected mimetype) Landry
Re: NEW: sysutils/vifm
Stuart Henderson said: > On 2016/02/02 21:58, Landry Breuil wrote: > > Oh, and the code in src/int/file_magic.c even has a fallback to use file > > %s -b --mime-type called via popen().. > > It would be nice to kill the other options and use file(1) from base > as the only detection method, it is *loads* safer. Well, the actual code is: | snprintf(command, sizeof(command), "file \"%s\" -b --mime-type", filename); Note double quotes. Of course no quoting is performed on filename. Thus: 1. If filename contains double quote, vifm sigfaults. 2. If filename is nasty, nasty things happen. Eg. I renamed a png image to "$(echo text)", and vifm opened it in vi. I guess filename "`doas rm -Rf $HOME/*`" will also pleasantly surprise user. -- Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
Stuart Henderson said: > On 2016/02/03 00:25, Dmitrij D. Czarkoff wrote: > > Stuart Henderson said: > > > On 2016/02/02 21:58, Landry Breuil wrote: > > > > Oh, and the code in src/int/file_magic.c even has a fallback to use file > > > > %s -b --mime-type called via popen().. > > > > > > It would be nice to kill the other options and use file(1) from base > > > as the only detection method, it is *loads* safer. > > > > Well, the actual code is: > > > > | snprintf(command, sizeof(command), "file \"%s\" -b --mime-type", > > filename); > > > > Note double quotes. Of course no quoting is performed on filename. > > Thus: > > > > 1. If filename contains double quote, vifm sigfaults. > > 2. If filename is nasty, nasty things happen. Eg. I renamed a png image > >to "$(echo text)", and vifm opened it in vi. I guess filename > >"`doas rm -Rf $HOME/*`" will also pleasantly surprise user. > > Ugh. I have seen CVEs assigned for smaller problems than that! I've added a naive patch to openbsd-wip version of this port. Vifm still opens renamed png in vi, but at least does not execute commands. -- Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
On 2016/02/03 00:25, Dmitrij D. Czarkoff wrote: > Stuart Henderson said: > > On 2016/02/02 21:58, Landry Breuil wrote: > > > Oh, and the code in src/int/file_magic.c even has a fallback to use file > > > %s -b --mime-type called via popen().. > > > > It would be nice to kill the other options and use file(1) from base > > as the only detection method, it is *loads* safer. > > Well, the actual code is: > > | snprintf(command, sizeof(command), "file \"%s\" -b --mime-type", filename); > > Note double quotes. Of course no quoting is performed on filename. > Thus: > > 1. If filename contains double quote, vifm sigfaults. > 2. If filename is nasty, nasty things happen. Eg. I renamed a png image >to "$(echo text)", and vifm opened it in vi. I guess filename >"`doas rm -Rf $HOME/*`" will also pleasantly surprise user. Ugh. I have seen CVEs assigned for smaller problems than that!
Re: NEW: sysutils/vifm
Landry Breuil said: > Tried with just the file backend enabled, it's "less" rich than the > gtk/libmagic combination but works for pdf/jpg/txt/mp3. No match for tgz, > proposes fuse-archivemount for .tar.gz, proposes text editor for > gpx/gsb... for the latter, the correct mimetype was found and the best > handler was proposed. I guess that's what you get for using file from > base which is ... basic. I somehow overlooked the fact that vifm only uses X11 to set window title. I bet people may live without this feature. (I thought it uses X11 for clipboard.) Provided that basic things work with file(1) backend, FLAVORs indeed don't seem a good idea. Attached tarball contains a non-FLAVORed port for vifm with all optional features disabled. Brief testing demonstrates that it is buggy (prints artifacts in file info dialog for some file names, provides different set of handlers for the files with same mime type, seldom picks different handlers for the same file). I believe that my patch makes file(1) usage in this port at least safer then it was. FLAVORed version is still available in openbsd-wip repo. I am not really interested in vifm, so I leave this port here as it is. -- Dmitrij D. Czarkoff vifm-0.8.1.tgz Description: application/tar-gz
Re: NEW: sysutils/vifm
On Wed, Feb 03, 2016 at 12:42:34AM +0100, Dmitrij D. Czarkoff wrote: > Stuart Henderson said: > > On 2016/02/03 00:25, Dmitrij D. Czarkoff wrote: > > > Stuart Henderson said: > > > > On 2016/02/02 21:58, Landry Breuil wrote: > > > > > Oh, and the code in src/int/file_magic.c even has a fallback to use > > > > > file > > > > > %s -b --mime-type called via popen().. > > > > > > > > It would be nice to kill the other options and use file(1) from base > > > > as the only detection method, it is *loads* safer. > > > > > > Well, the actual code is: > > > > > > | snprintf(command, sizeof(command), "file \"%s\" -b --mime-type", > > > filename); > > > > > > Note double quotes. Of course no quoting is performed on filename. > > > Thus: > > > > > > 1. If filename contains double quote, vifm sigfaults. > > > 2. If filename is nasty, nasty things happen. Eg. I renamed a png image > > >to "$(echo text)", and vifm opened it in vi. I guess filename > > >"`doas rm -Rf $HOME/*`" will also pleasantly surprise user. > > > > Ugh. I have seen CVEs assigned for smaller problems than that! > > I've added a naive patch to openbsd-wip version of this port. Vifm > still opens renamed png in vi, but at least does not execute commands. better report it directly upstream then ? :) Landry
Re: NEW: sysutils/vifm
On Tue, Feb 02, 2016 at 05:18:13PM +0100, Dmitrij D. Czarkoff wrote: > Tobias Ulmer said: > > What's the point when it requires half of GNOME? You should call the > > package gvifm... > > GTK+ is not half of GNOME. Is this supposed to make me feel better? :p > > -- > Dmitrij D. Czarkoff >
Re: NEW: sysutils/vifm
Tobias Ulmer said: > What's the point when it requires half of GNOME? You should call the > package gvifm... GTK+ is not half of GNOME. -- Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
Tobias Ulmer said: > On Tue, Feb 02, 2016 at 05:18:13PM +0100, Dmitrij D. Czarkoff wrote: > > Tobias Ulmer said: > > > What's the point when it requires half of GNOME? You should call the > > > package gvifm... > > > > GTK+ is not half of GNOME. > > Is this supposed to make me feel better? :p It makes *me* feel better. I have all of the dependencies anyway, just because of browser. -- Dmitrij D. Czarkoff
Re: NEW: sysutils/vifm
What's the point when it requires half of GNOME? You should call the package gvifm... CONFIGURE_ARGS += --without-gtk --without-libmagic --without-X11 --without-dyn-X11 (libmagic is a security disaster waiting to happen in a file manager) On Thu, Jan 28, 2016 at 06:18:59PM +0100, Rafael Sadowski wrote: > hey @ports and vifm friends, > > here is an up-to-date vifm port. Tested on amd64 by me and positive test > feedback from Uwe Werler. Port request by Uwe. > > I found a thread on ports@: > https://marc.info/?l=openbsd-ports=144944041505080=2 > > I can not confirm runtime problems or memory usage oversize at buildtime. > > pkg/DESCR: > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > vifm gives you complete keyboard control over your files without having > to learn a new set of commands. It goes not just about vi[m] like > keybindings, but also about modes, options, registers, commands and other > things you might already like in vi[m]. > > Best regards, > > Rafael
Re: NEW: sysutils/vifm
> hey @ports and vifm friends, > > here is an up-to-date vifm port. Tested on amd64 by me and positive test > feedback from Uwe Werler. Port request by Uwe. > > I found a thread on ports@: > https://marc.info/?l=openbsd-ports=144944041505080=2 > > I can not confirm runtime problems or memory usage oversize at buildtime. > > pkg/DESCR: > Vifm is a two panel ncurses based vi[m] like file manager. If you use vi, > vifm gives you complete keyboard control over your files without having > to learn a new set of commands. It goes not just about vi[m] like > keybindings, but also about modes, options, registers, commands and other > things you might already like in vi[m]. > > Best regards, > > Rafael Up to now it work's like a charme on -current. Thanks Rafael!
Re: NEW: sysutils/vifm
On Thu, Jan 28, 2016 at 06:18:59PM +0100, Rafael Sadowski wrote: > here is an up-to-date vifm port. Tested on amd64 by me and positive > test feedback from Uwe Werler. Port request by Uwe. Tested positive on amd64. Love it! Thank you very much. Hope it gets imported. Regards, Erling > I found a thread on ports@: > https://marc.info/?l=openbsd-ports=144944041505080=2 > > I can not confirm runtime problems or memory usage oversize at > buildtime. > > pkg/DESCR: > Vifm is a two panel ncurses based vi[m] like file manager. If you use > vi, vifm gives you complete keyboard control over your files without > having to learn a new set of commands. It goes not just about vi[m] > like keybindings, but also about modes, options, registers, commands > and other things you might already like in vi[m]. > > Best regards, > > Rafael
