Re: NEW: sysutils/vifm

2016-06-24 Thread Stuart Henderson
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

2016-06-12 Thread Dmitrij D. Czarkoff
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

2016-06-12 Thread Dmitrij D. Czarkoff
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

2016-06-12 Thread Stuart Henderson
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

2016-06-12 Thread Dmitrij D. Czarkoff
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

2016-06-09 Thread Dmitrij D. Czarkoff
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

2016-06-09 Thread Stuart Henderson
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

2016-06-09 Thread Landry Breuil
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

2016-06-08 Thread Rafael Sadowski
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

2016-06-08 Thread Landry Breuil
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

2016-06-07 Thread Uwe Werler
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



NEW: sysutils/vifm

2016-06-07 Thread 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


vifm.tar.gz
Description: application/tar-gz


Re: NEW: sysutils/vifm

2016-03-13 Thread Dmitrij D. Czarkoff
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

2016-03-13 Thread Rafael Sadowski
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



NEW: sysutils/vifm

2016-02-25 Thread Rafael Sadowski
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


vifm.tar.gz
Description: application/tar-gz


Re: NEW: sysutils/vifm

2016-02-03 Thread Dmitrij D. Czarkoff
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

2016-02-02 Thread Landry Breuil
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

2016-02-02 Thread Landry Breuil
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

2016-02-02 Thread Rafael Sadowski
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

2016-02-02 Thread Dmitrij D. Czarkoff
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

2016-02-02 Thread Landry Breuil
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

2016-02-02 Thread Stuart Henderson
> 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

2016-02-02 Thread Dmitrij D. Czarkoff
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

2016-02-02 Thread Tobias Ulmer
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

2016-02-02 Thread Stefan Sperling
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

2016-02-02 Thread Stuart Henderson
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

2016-02-02 Thread Landry Breuil
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

2016-02-02 Thread Rafael Sadowski
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

2016-02-02 Thread Landry Breuil
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

2016-02-02 Thread Dmitrij D. Czarkoff
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

2016-02-02 Thread Dmitrij D. Czarkoff
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

2016-02-02 Thread Stuart Henderson
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

2016-02-02 Thread Dmitrij D. Czarkoff
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

2016-02-02 Thread Landry Breuil
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

2016-02-02 Thread Tobias Ulmer
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

2016-02-02 Thread Dmitrij D. Czarkoff
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

2016-02-02 Thread Dmitrij D. Czarkoff
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

2016-02-02 Thread Tobias Ulmer
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

2016-01-29 Thread Uwe Werler

> 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

2016-01-29 Thread Erling Westenvik
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



NEW: sysutils/vifm

2016-01-28 Thread Rafael Sadowski
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


vifm.tar.gz
Description: application/tar-gz


Re: vifm

2015-12-06 Thread Anthony J. Bentley
Predrag Punosevac writes:
> I noticed that vifm has been removed from the OpenBSD port three prior
> to 5.8 release. Are there technical reasons for such decision (I
> remember pains to initial import vifm into the port three due to the
> code quality)? It looks like vifm got many new features which might have
> triggered the decision. 
> 
> I just tried ranger instead of vifm but it seems overkill for an
> occasional user like myself (I found vifm sometimes useful with ssh/tmux
> sessions).

See the commit message...

"remove; it's been runtime broken since forever and the latest version isn't
any better either as confirmed by landry@. maintainer is MIA too."



vifm

2015-12-06 Thread Predrag Punosevac
I noticed that vifm has been removed from the OpenBSD port three prior
to 5.8 release. Are there technical reasons for such decision (I
remember pains to initial import vifm into the port three due to the
code quality)? It looks like vifm got many new features which might have
triggered the decision. 

I just tried ranger instead of vifm but it seems overkill for an
occasional user like myself (I found vifm sometimes useful with ssh/tmux
sessions).

Best,
Predrag



Re: New: misc/vifm

2009-08-09 Thread Landry Breuil
On Sat, Aug 08, 2009 at 08:58:13PM +0200, Landry Breuil wrote:
 On Sat, Aug 08, 2009 at 04:22:08PM +0200, Tobias Ulmer wrote:
  First try that doesn't crash on amd64 within seconds.
  
  Removes the most evil things gcc warns about and moves malloc out of the
  signal handler. There is without a doubt, much more to repair...
 
 For sure.. with your patches, it still explodes on sparc64 at the same point..
 volunteers for code reading  fixing  forwarding patches upstream needed :)

ok, so here's a version that works (basic testing)
@macppc/sparc64/i386/alpha/amd64
- allocating :
char file_name[view-window_width -2];
- and accessing :
file_name[view-window_width +1]
is no good.. but the code does indeed lots of scarier things :)

While here, install vifmrc to share/vifm to remove the annoying warning
upon first startup, where it tried to copy the file from there to
~/.vifm.

Comments/oks ?

Landry


vifm3.tgz
Description: application/tar-gz


Re: New: misc/vifm

2009-08-09 Thread Aaron Stellman
On Sun, Aug 09, 2009 at 12:49:46PM +0200, Landry Breuil wrote:
 On Sat, Aug 08, 2009 at 08:58:13PM +0200, Landry Breuil wrote:
  On Sat, Aug 08, 2009 at 04:22:08PM +0200, Tobias Ulmer wrote:
   First try that doesn't crash on amd64 within seconds.
   
   Removes the most evil things gcc warns about and moves malloc out of the
   signal handler. There is without a doubt, much more to repair...
  
  For sure.. with your patches, it still explodes on sparc64 at the same 
  point..
  volunteers for code reading  fixing  forwarding patches upstream needed :)
 
 ok, so here's a version that works (basic testing)
 @macppc/sparc64/i386/alpha/amd64
 - allocating :
 char file_name[view-window_width -2];
 - and accessing :
 file_name[view-window_width +1]
 is no good.. but the code does indeed lots of scarier things :)
 
 While here, install vifmrc to share/vifm to remove the annoying warning
 upon first startup, where it tried to copy the file from there to
 ~/.vifm.
 
 Comments/oks ?

Thanks, works fine on amd64.
Since you've done all the patching, you were the one who originally
posted the port two years ago, and I don't have access to sparc64 -- I
probably don't deserve to be a maintainer of this port ;-).



Re: New: misc/vifm

2009-08-08 Thread Landry Breuil
On Fri, Aug 07, 2009 at 04:06:53PM -0700, Aaron Stellman wrote:
 Hello ports@,
 attached is the ports of vifm -- ncurses file manager with vi
 keybindings.
 
 cat pkg/DESCR
 Vifm is a ncurses based file manager with vi like keybindings. If you
 use vi, vifm gives you complete keyboard control over your files without
 having to learn a new set of commands.

I had this in my tree at some point (maybe 0.3), and i remember its code
was rather ugly. Works on i386, but seems to do really bad things (tm)
on sparc64 just at startup :

Program received signal SIGABRT, Aborted.
__stack_smash_handler (func=0x21d058 moveto_list_pos, damaged=-738134664) at 
/usr/src/lib/libc/sys/stack_protector.c:91
  /usr/src/lib/libc/sys/stack_protector.c: No such file or directory.
in /usr/src/lib/libc/sys/stack_protector.c
(gdb) bt
#0  __stack_smash_handler (func=0x21d058 moveto_list_pos, damaged=-738134664) 
at /usr/src/lib/libc/sys/stack_protector.c:91
#1  0x0010c074 in moveto_list_pos (view=0x720698, pos=0) at 
filelist.c:553
#2  0x00102e04 in main (argc=1, argv=0xfffe9a68) at vifm.c:26

I don't see the reason of this crash, will investigate a bit, but i'll
appreciate if others could have a look too.

Landry



Re: New: misc/vifm

2009-08-08 Thread Tobias Ulmer
On Sat, Aug 08, 2009 at 11:12:02AM +0200, Landry Breuil wrote:
 On Fri, Aug 07, 2009 at 04:06:53PM -0700, Aaron Stellman wrote:
  Hello ports@,
  attached is the ports of vifm -- ncurses file manager with vi
  keybindings.
  
  cat pkg/DESCR
  Vifm is a ncurses based file manager with vi like keybindings. If you
  use vi, vifm gives you complete keyboard control over your files without
  having to learn a new set of commands.
 
 I had this in my tree at some point (maybe 0.3), and i remember its code
 was rather ugly. Works on i386, but seems to do really bad things (tm)
 on sparc64 just at startup :
 
 Program received signal SIGABRT, Aborted.
 __stack_smash_handler (func=0x21d058 moveto_list_pos, damaged=-738134664) 
 at /usr/src/lib/libc/sys/stack_protector.c:91
   /usr/src/lib/libc/sys/stack_protector.c: No such file or directory.
 in /usr/src/lib/libc/sys/stack_protector.c
 (gdb) bt
 #0  __stack_smash_handler (func=0x21d058 moveto_list_pos, 
 damaged=-738134664) at /usr/src/lib/libc/sys/stack_protector.c:91
 #1  0x0010c074 in moveto_list_pos (view=0x720698, pos=0) at 
 filelist.c:553
 #2  0x00102e04 in main (argc=1, argv=0xfffe9a68) at vifm.c:26
 
 I don't see the reason of this crash, will investigate a bit, but i'll
 appreciate if others could have a look too.
 
 Landry

That's not surprising, from memory the code uses sizeof(buf)
when it actually wanted bufsize in a number of places. I will take a
look as well.

Tobias



Re: New: misc/vifm

2009-08-08 Thread Tobias Ulmer
First try that doesn't crash on amd64 within seconds.

Removes the most evil things gcc warns about and moves malloc out of the
signal handler. There is without a doubt, much more to repair...


vifm2.tar.gz
Description: application/tar-gz


Re: New: misc/vifm

2009-08-08 Thread Landry Breuil
On Sat, Aug 08, 2009 at 04:22:08PM +0200, Tobias Ulmer wrote:
 First try that doesn't crash on amd64 within seconds.
 
 Removes the most evil things gcc warns about and moves malloc out of the
 signal handler. There is without a doubt, much more to repair...

For sure.. with your patches, it still explodes on sparc64 at the same point..
volunteers for code reading  fixing  forwarding patches upstream needed :)

Landry



Re: New: misc/vifm

2009-08-08 Thread Predrag Punosevac
Landry Breuil lan...@rhaalovely.net wrote:

 On Sat, Aug 08, 2009 at 04:22:08PM +0200, Tobias Ulmer wrote:
  First try that doesn't crash on amd64 within seconds.
  
  Removes the most evil things gcc warns about and moves malloc out of the
  signal handler. There is without a doubt, much more to repair...

 For sure.. with your patches, it still explodes on sparc64 at the same point..
 volunteers for code reading  fixing  forwarding patches upstream needed :)

 Landry

I would like to bring to your attention two facts:

1. Somebody did try to port vifm to OpenBSD few years ago. There is 
the reason vifm is still not in ports.

2. Good luck with fixing things upstream. My fellow Tucsonian who 
coded vifm did that in order to learn programming language C :-)
He is retired these days so am not sure if he is interested in 
brushing up his programming skills.

Best,
Predrag



Re: New: misc/vifm

2009-08-08 Thread Landry Breuil
On Sat, Aug 08, 2009 at 05:32:16PM -0400, Predrag Punosevac wrote:
 Landry Breuil lan...@rhaalovely.net wrote:
 
  On Sat, Aug 08, 2009 at 04:22:08PM +0200, Tobias Ulmer wrote:
   First try that doesn't crash on amd64 within seconds.
   
   Removes the most evil things gcc warns about and moves malloc out of the
   signal handler. There is without a doubt, much more to repair...
 
  For sure.. with your patches, it still explodes on sparc64 at the same 
  point..
  volunteers for code reading  fixing  forwarding patches upstream needed :)
 
  Landry
 
 I would like to bring to your attention two facts:
 
 1. Somebody did try to port vifm to OpenBSD few years ago. There is 
 the reason vifm is still not in ports.

Funny, looking at the archives... i found out it was myself who already
ported it :)

 2. Good luck with fixing things upstream. My fellow Tucsonian who 
 coded vifm did that in order to learn programming language C :-)
 He is retired these days so am not sure if he is interested in 
 brushing up his programming skills.

Well - we can still keep the patches local anyway, or someone can still
take over maintenance of it - thanks free software :)

Landry



Re: [new] vifm

2007-11-20 Thread Paul Irofti
On Mon, Nov 19, 2007 at 04:27:59PM +0100, Landry Breuil wrote:
 Hi,
 
 a small port for vifm, a ncurses based file manager with vi like
 keybindings.
 
 Works fine for me on i386, it's rather basic but may be useful to
 someone..
 
 cf http://vifm.sourceforge.net/docs.html for default keybindings.
 
 port is here : http://gcu.info/~gaston/ports/vifm.tar.gz
 
 Comments ? Ok ?
 
 Landry
 

Works fine on amd64.



[new] vifm

2007-11-19 Thread Landry Breuil
Hi,

a small port for vifm, a ncurses based file manager with vi like
keybindings.

Works fine for me on i386, it's rather basic but may be useful to
someone..

cf http://vifm.sourceforge.net/docs.html for default keybindings.

port is here : http://gcu.info/~gaston/ports/vifm.tar.gz

Comments ? Ok ?

Landry



Re: [new] vifm

2007-11-19 Thread Pea
Le Mon, 19 Nov 2007 16:27:59 +0100,
Landry Breuil [EMAIL PROTECTED] a écrit :

 Hi,
 
 a small port for vifm, a ncurses based file manager with vi like
 keybindings.
 
 Works fine for me on i386, it's rather basic but may be useful to
 someone..
 
 cf http://vifm.sourceforge.net/docs.html for default keybindings.
 
 port is here : http://gcu.info/~gaston/ports/vifm.tar.gz
 
 Comments ? Ok ?
 
 Landry
 
 
Hi,

Tested on @i386: Ok.
Nice tool :)

Pea



Re: [new] vifm

2007-11-19 Thread Mike Erdely
On Mon, Nov 19, 2007 at 04:27:59PM +0100, Landry Breuil wrote:
 a small port for vifm, a ncurses based file manager with vi like
 keybindings.
 
 Works fine for me on i386, it's rather basic but may be useful to
 someone..

Works for me on i386 and macppc.  It dumps core on sparc64.
On both sparc64 and macppc, I get this when I start vifm (but not i386):
Unable to find configuration file.
cp: /usr/local/share/vifm/vifmrc0.2: No such file or directory

-ME



Re: [new] vifm

2007-11-19 Thread Landry Breuil
On Mon, Nov 19, 2007 at 01:20:34PM -0500, Mike Erdely wrote:
 On Mon, Nov 19, 2007 at 04:27:59PM +0100, Landry Breuil wrote:
  a small port for vifm, a ncurses based file manager with vi like
  keybindings.
  
  Works fine for me on i386, it's rather basic but may be useful to
  someone..
 
 Works for me on i386 and macppc.  It dumps core on sparc64.
 On both sparc64 and macppc, I get this when I start vifm (but not i386):
 Unable to find configuration file.
 cp: /usr/local/share/vifm/vifmrc0.2: No such file or directory

Funny, this file isn't listed in PLIST... I think i'll give a second
chance to this port by patching source, removing dumb helper scripts and
fix coredump on sparc64... stay tuned.

Landry



Re: Request for new port: vifm

2005-11-26 Thread Andreas Bihlmaier
Hello ports@ again,

sorry for answering my own mail, but I did some more research:

To make vifm compile you just have to install automake 1.7 (I used 1.9) change
the links in vifm/ to point to
/usr/local/share/automake-1.9/{depcomp,install-sh,missing,mkinstalldirs}

The patch I posted before has to be used (still don't know why, older version
of ncurses on openbsd?).

I found about about more niffty features, one is that you can define default
programs for every file type, so vifm will use those programms to open them.

As I said EVERYBODY working with VI[M] and many files should have a look at it,
the ease of use is just impressive.

Since I didn't get any reply so far what could I do to get it adopted as an
official port?

Btw, it works (at least) on:
i386
amd64
(not on hppa and vax (there is no new enough autoconf :))


Regards,
ahb



Request for new port: vifm

2005-11-23 Thread Andreas Bihlmaier
Hello ports@,

I would really like to see vifm [1] in the ports tree, because it is a really
nice and comfortable file manager (like mc), but with vi key bindings.

I basically downloaded the source, untared it, fixed all the symlinks in the
vifm directory and had to comment out one line in vimfm/src/ui.c
I don't know where the symlinks SHOULD go, I just linked it against files I
found with the same name (yeah it worked somehow :)

This is not a fix of course, but it enabled me to compile it and it runs just
fine. I'm sure somenone here (having much more C/ncurses knowledge) could fix
it quickly.


#--- dirty_hack ---#
--- vifm/src/ui.c   Sun Jul 17 23:51:28 2005
+++ vifm2/src/ui.c  Thu Nov 24 07:57:51 2005
@@ -324,7 +324,7 @@
 
ioctl(0, TIOCGWINSZ, ws);
 
-   resize_term(ws.ws_row, ws.ws_col);
+/* resize_term(ws.ws_row, ws.ws_col); */
 
getmaxyx(stdscr, screen_y, screen_x);
#--#


Since I'm sure many developers/ports-maintainers are using vi[m] as well, would
it be possible to make a port and include it?

[1] http://vifm.sourceforge.net/

Regards,
ahb

Please CC me, otherwise I have to read it in the archives (no problem either).