>On Sep 21 22:37:11, [email protected] wrote: >> On 2015/09/21 21:31, Jan Stary wrote: >> > On Sep 17 07:30:23, [email protected] wrote: >> > > update to libmagic (file) 5.25 >> > >> > What is the relation of OpenBSD's own new file(1) to devel/libmagic? >> >> No code relation. libmagic is a package built from sources of the old >> file(1) (but only provides the library part, not the executable). >> >> > The magic(5) file used by file(1) is version 4.24, while >> > the magic(4) file that comes with libmagic is version 5.25. >> > Can libmagic use the /etc/magic that comes with file(1)? >> > It doesn't seem to be the case: the naive program below >> > shows a bunch of errors when trying to magic_compile(), >> > starting with >> > >> > /tmp/magfile, 627: Warning: string modifier `B' invalid >> > /tmp/magfile, 628: Warning: Current entry does not yet have >> > a description for ad ding a MIME type >> > >> > Is this the discrepancy in the magic file format version? >> > Does that mean that /etc/magic is only used/usable by file(1), >> > but ports using libmagic (e.g. sox) can only use the magic file >> > that comes with it, /usr/local/share/misc/magic.mgc ? >> >> magic.mgc is compiled from files in magdir in the source tree. >> If you take those input files and cat them into a single /etc/magic >> file, that file is usable with file(1) in base, but the reverse isn't >> true, libmagic's parser doesn't like some of the things in base's >> /etc/magic (e.g. lots of the uses of %ld) so for now libmagic needs >> to use its own file. > >Thanks for the insight. > >Are there any plans to eventually have a base libmagic >that would work with base's file/magic? >(Possibly isolating what's in file/magic* into a library?)
No, no, no. First off, nicm's new file is a privsep-jailed file reviewer. It uses new pattern matching logic written with greater care. Even so, that new logic is not trusted, and it jails itself and uses a seperate process, with systrace in the current code and perhaps tame() in the future, which stops a parsing mistake from escalating into horror. Such seperation cannot be done transparently in a library with a public interface. The secret sauce that makes new file(1) "safer", still does not make the concept of magic matching "safe". Instead, the long term goal should be for "ports" software to STOP using ideas like "libmagic". It is an unsafe practice, through and through. libmagic and file(1) are very much like giving toddlers loaded guns. If you have a data file you want to discern the "type" of, is it likely that it may contain unknown and potentially HOSTILE content? Did the data file come off the internet? I mean really -- how do you encourage people to use libmagic and file(1) only on safe files. How do you discourage people from using file(1) or libmagic against files they got off the internet? Is there really a way to split these patterns? No. The magic matching model got crazy decades ago. It is a string matching library against hostile string input. The entire subsystem stopped just short of being turing complete. It grew patterns without any concern for safety. Do your part to discourage use of such ideas in security sensitive places. Which increasingly is nearly everything. Go look in the ports tree for what uses libmagic. Takes 2 minutes. Few of you can walk away feeling good about it.
