05:26:13 alright...soliciting advice...I was going to write the port for gitstatus. 05:26:47 They have a custom build script which works on FreeBSD. I'm wondering...should I preserve it or try to write a Makefile? 05:27:16 The problem is...damn, this is confusing. Between missing headers and custom dependencies, writing a Makefile might become a serious ordeal 05:27:33 Is it normal to run custom build scripts rather than having a simple, clean Makefile? 05:31:14 i wouldn't say it's "normal" but if the package doesn't provide a makefile and expects you to use their build script, and the script works on freebsd, i would just keep using it 05:31:31 Are there other exmaples of that? 05:31:32 there's not benefit from writing a new build system unless you're going to submit it upstream, and iirc you said this project is defunct upstream 05:31:40 devel/boost-jam 05:31:52 thank you! 05:32:47 btw...seems kinda insecure to have thousands of people running a custom build script on their machines. 05:33:05 no more insecure than using a makefile, which also contains arbitrary shell commands 05:33:24 True, but in theory those shell commands are visible within FreeBSD 05:33:29 whereas a build script can change arbitrarily. 05:34:08 you mean because make prints the commands it runs while building? but you can just prefix the command with '@' to make it not do that 05:34:30 I don't follow you? 05:35:15 lets say I have a package called 'farhan' and it has a custom build script 'buildme.sh'. You can look at MAKE_CMD=buildme.sh and know that buildme.sh is running. 05:35:30 But I can arbitrarily change buildme.sh's contents. 05:35:45 yes, but if your package ships a Makefile, you could arbitrary change the Makefile's contents? 05:36:09 this is why distinfo includes the hash of the dist file, to know it's unchanged from when the maintainer submitted the port 05:37:13 you're right about boost-jam, I might use that as a template. 05:37:21 And...I am not familiar with distinfo, will research. 05:37:42 distinfo is one of the files you submit with your port along with Makefile, pkg-descr, etc., it's described in the porter's handbook 05:38:07 it isn't present with boost-jam 05:38:24 oh yes! I did read about that! Sorry, so many terms/concepts at once and its hard to remember just yet. 05:38:39 no, that's quite odd and i'm not sure why boost-jam doesn't have a distinfo, but almost all other ports do 05:39:07 ah, it's because boost-jam uses the distinfo from boost-all 05:39:13 and you're familiar with gitstatus? 05:39:17 (because it's a part of boost, not a standalone package) 05:39:24 i have never heard of gitstatus before, no 07:54:03 Hi. I just installed dma (DragonFly Mail Agent) on a Debian machine, since I'm already using happily under FreeBSD. I notice that under Debian there's no need to have the configuration files world readable: they are readable by the "mail" group, and /usr/sbin/dma is a setgid executable, having group mail of course 07:54:32 I think it is a good idea. If it actually is so, would it make sense to have the same setup under FreeBSD? Perhaps a default even 07:54:44 farhan: for the ports framework there is just some command(s) you run to build the project, the default is using make and some other build systems have support via USES, but you can write the do-build target in the port yourself, same with do-install and do-fetch (but you should override that last one only in really rare cases) 07:55:47 dacav: i would be mildly opposed to think, i think setuid executables are bad and if you want something unusual you're better off installing a proper MTA 07:55:51 s/to think/so this 07:56:51 ivy: it is setgid to a 'mail' group 07:57:07 dacav: yes 07:57:30 setuid executables introduce potential security issues to all systems that executable is installed on, but this functionality would only be used by a small subset of systems 07:57:31 why do you think it is bad? 07:58:09 OK, I understand the idea: if an exploit exists on that binary, you get to run arbitrary code with those permission granted 07:58:12 do you know if it's installed this way on DFBSD? 07:58:37 But in this specific case the permissions would be those accorded to the `mail` group, which would be reading of /etc/dma/* 07:58:53 ...which is already the case for any user 07:59:04 so my argument is that there's no big risk 07:59:23 I don't know if it is installed this way on DFBSD 07:59:29 dacav: i don't think that is correct, e.g. /var/mail is by default 0775 root:mail, so anyone with gid mail can write arbitrary files there 07:59:30 I don't own a DFBSD system :) 07:59:54 gid mail might also be used for other things i can't think of off hand 08:00:29 I see. Would it make sense to have a different group perhaps? Or would it be too bloaty? 08:00:34 perhaps if we added a new 'dma' group and made dma setgid dma, that would be more reasonable 08:00:57 :) 08:01:23 * dacav has got to go :( 08:01:36 dacav: you can find a PR and cc ivy@, i think this is not an unreasonable idea 08:01:47 find a PR? 08:01:48 dacav: however we need to check with DF to make sure the code has been audited for setgid installation 08:01:52 s/find a PR/file a PR 08:01:53 do you mean file a pull request? 08:01:56 ok 08:02:00 I will do that later :) 08:02:03 I never did it 08:02:11 as in file a problem report at https://bugs.freebsd.org 08:02:37 Sure enough! I'll be back in the evening! Thanks for your time 08:02:37 when you do that, put ivy⊙fo in the Cc: field 08:04:51 all this MTA talk reminds me I need to patch my qmail-remote executable (-: 08:05:18 FAQ. «are you a time traveller» no.