[00:11] <[Shiba]> I'm considering implementing a more advanced "autorun" feature for usb storage media on OpenWRT. The idea is to automate application startup from external media securely. The implementation would include strong cryptographic verification of autorun scripts using sha256. there would be a user-defined database of sha256 hashes stored on the flash rom, one hash for each trusted script. is there any chance that such a feat
[00:11] <[Shiba]> ure -- if submitted as a patch under the gpl -- would be committed?
[00:13] <[Shiba]> Please keep in mind that I am not asking the OpenWRT developers to do the work for me. I plan to write the application myself and make the necessary modifications to the openwrt rc5 tree, then submit the patch
[00:14] <[Shiba]> if there is no interest, or if said application will never be considered for inclusion, please let me know so I don't waste me time.
[00:14] <[Shiba]> my*
[00:40] <nbd> [Shiba]: it can be added as an optional package if you design it that way and don't touch base system scripts
[00:41] <nbd> [Shiba]: but you should consider writing it for buildroot-ng
[00:42] <nbd> [Shiba]: are you going to use the application yourself or is this just an idea that you had?
[00:48] <db90h> it's hard to encourage people to code for the buildroot-ng tree when it's so far from being widely deployed..
[00:48] <[Shiba]> well it is in response to a specific need of mine
[00:48] <[Shiba]> I don't actually need the higher level of functionality that a security-enabled autorun system would provide
[00:48] <[Shiba]> but to be acceptable for deployment, it needs to be secure
[00:49] <[Shiba]> and it just occurred to me that even if a script is signed properly, that doesn't mean it won't do nasty things
[00:49] <[Shiba]> like maybe a signed script is copied onto another device and the applications it calls are modified or replaced
[00:49] <nbd> you don't actually need to make the package for buildroot-ng directly
[00:50] <nbd> but you should consider using its scripts for config handling
[00:50] <nbd> in buildroot-ng, we want to have every system config file in the same format
[00:50] <nbd> at least for all services where it makes sense
[00:50] <[Shiba]> well I was thinking of adding it as a patch
[00:50] <[Shiba]> see this would complement the hotplug daemon
[00:50] <nbd> you don't need to change the base files at all
[00:51] <[Shiba]> it is inserted into the hotplug scripts
[00:51] <nbd> you can make it a package that installs scripts into /etc/hotplug.d
[00:51] <[Shiba]> well I suppose I could write it as a system daemon
[00:51] <[Shiba]> ah
[00:51] <nbd> no need to do a daemon either
[00:51] <nbd> put it in /etc/hotplug.d/<type>
[00:52] <[Shiba]> what sort of configuration file would I need to build?
[00:52] <[Shiba]> I was thinking that I would keep it simple, one hash per line
[00:52] <nbd> well, you want to have a config file that contains the signatures and other checks for files, right?
[00:52] <[Shiba]> yes
[00:53] <nbd> the config file format is grouped into sections and options
[00:53] <nbd> it looks like this
[00:53] <[Shiba]> hmmm I think I would probably need to have it scan the shell script for references to executable files and store their hashes too
[00:53] <nbd> config <section type> [<section name>]
[00:54] <nbd> option <name> <value>
[00:54] <[Shiba]> like the X config eh?
[00:54] <nbd> similar
[00:54] <nbd> but this format is very easy to parse in shell
[00:54] <nbd> it's flexible enough
[00:55] <nbd> and we have shell/awk code for manipulating these config files as well
[00:55] <[Shiba]> why didn't you go with xml?
[00:55] <db90h> wouldn't be as easy to parse, that's for sure
[00:55] <nbd> i wanted something simple
[00:56] <nbd> something that can be read by stupid shell code with no effort
[00:56] <[Shiba]> mmm good point
[00:56] <groz_> xml = sure fired way to add tons of bloat to a simple concept
[00:56] <db90h> how many packages use this new config format as of now?
[00:56] <nbd> db90h: network config and wireless config
[00:56] <db90h> hmm
[00:56] <db90h> i didn't know u guys had got that far
[00:57] <[Shiba]> is there some sort of "RFC" for this config format, or at leasta complete specification I can read?
[00:57] <db90h> boy it'd be easy to make shell or http based configurators with this
[00:57] <nbd> [Shiba]: no documentation yet, unfortunately
[00:57] <groz_> if you are truely paranoid about scripts etc being modified, why not just build your image with 'final configuration' in it, and then dont pivot onto a writeable file system
[00:57] <groz_> now your scripts are locked, and permanently locked
[00:57] <[Shiba]> well thats not the point
[00:58] <[Shiba]> I want to build a system that allows autorun from external media
[00:58] <[Shiba]> say you have some data you want to make available on nfs from the media
[00:58] <[Shiba]> you'd be able to plug the disk in and have it automagically add the config to /etc/exports when it was plugged in
[00:58] <[Shiba]> then restart the nfs daemons
[00:58] <[Shiba]> all without direct user intervention
[00:59] <[Shiba]> of course then you'd have the problem of removing said shares when the device was unplugged
[00:59] <[Shiba]> but thats something I'll have to find a way to deal with
[01:00] <groz_> hotplug is ur friend
[01:00] <[Shiba]> well yes I know
[01:00] <[Shiba]> but when hte media is unplugged, the possibility to read scripts to remove its shares from the media is gone
[01:00] <[Shiba]> perhaps I could create some sort of temp file describing what was done in /tmp
[01:01] <[Shiba]> the idea is to make a secure autorun available for usb media
[01:01] <[Shiba]> of course you don't want autorun to execute malicious code, so there have to be checks in place
[01:02] <[Shiba]> which is why I'm considering using sha256 for application signatures
[01:02] <db90h> so if the autorun scripts are signed for secuirity, who authenticates the signer? is there user prompting?
[01:02] <[Shiba]> well none of the autorun scripts get executed unless their signatures are stored on flash rom
[01:02] <[Shiba]> the user has to set it up initially
[01:02] <db90h> oh, ok, so a pre-included list of valid sigs
[01:02] <groz_> use certificates, and, pre-load the box with the 'allwed signer' certs
[01:02] <[Shiba]> yes
[01:03] <[Shiba]> but that presents another problem
[01:03] <[Shiba]> using the signed script on another media and replacing called executables with different ones
[01:03] <[Shiba]> so I have to think about how to address that
[01:04] <nbd> i wrote a small example for you that shows how the config stuff works
[01:04] <nbd> http://pastebin.ca/119648
[01:04] <[Shiba]> thank you
[01:04] <nbd> oh, wait
[01:04] <nbd> there's a typo in there
[01:05] <nbd> http://pastebin.ca/119650
[01:05] <nbd> the functions are not in the whiterussian tree yet, but will be added soon
[01:05] <nbd> i mean the config_* functions
[01:05] <[Shiba]> okay
[01:05] <nbd> when you define config_cb() and option_cb(), they are used as 'callbacks' for sections and options
[01:06] <nbd> so you can have your script process the configuration options interactively if you want
[01:06] <nbd> but you can also use the config_get function to process them at a later time
[01:06] <[Shiba]> ah, nice
[01:07] <[Shiba]> I could script most of the interface using ash, and just use sha256sum to verify signatures
[01:07] <groz_> will config_set() re-write the files :)
[01:07] <nbd> config_set doesn't change the files
[01:07] <groz_> lol
[01:07] <[Shiba]> I was thinking I would have to parse the config file in C but tha tmay be unnecessary
[01:07] <nbd> i have a separate script for that
[01:08] <nbd> config_set only changes the config state in the environment
[01:08] Action: groz_ hunts around for a 'yet'
[01:08] <nbd> [Shiba]: it is unnecessary
[01:08] <[Shiba]> yes it would be nice to just use getenv()
[01:10] <nbd> this config stuff is so easy and fast enough, because it simply defines the shell functions config() and option() and then includes the config file as shell code :)
[01:10] <nbd> no need to write a custom parser when the shell already does what you need :)
[01:10] <[Shiba]> thats nice
[01:12] <[Shiba]> but this isn't available in rc5
[01:12] <[Shiba]> which is really a bummer :((
[01:12] <nbd> i can add the functions to svn tonight
[01:12] <[Shiba]> when is rc6 due?
[01:12] <nbd> and then you can just copy over your modified functions.sh
[01:12] <[Shiba]> oh that would be nice
[01:12] <nbd> and rc6 will be released very soon
[01:13] <[Shiba]> yes please include the parsing routines in rc6 ;)
[01:14] <[Shiba]> does anyone know offhand if gpg is available in WR?
[01:14] <[Shiba]> that would make it dead simple to add hashing to files ;)
[01:15] <groz_> if it's not, should be rather trivial to add no ?
[01:15] <[Shiba]> well yes, but there is space to consider
[01:15] <[Shiba]> the gpg binary on my system is 783kb
[01:16] <[Shiba]> thats a lot to ask a user to install for autorun functionality
[01:16] <CIA-17> nbd * r4492 /branches/whiterussian/openwrt/package/base-files/default/etc/functions.sh: add config parsing functions from buildroot-ng to whiterussian
[01:16] <nbd> :)
[01:16] <[Shiba]> niiiiice
[01:16] <[Shiba]> thank you nbd!
[01:17] <[Shiba]> hmm so it may be worth it to use sha256 instead of a PKCS due to space constraints
[01:18] <[Shiba]> considering that I can get an sha256 implementation that consumes less than 40kb uncompressed
[01:18] <nbd> makes sense
[01:18] <groz_> if you are going to do it, make it flexible
[01:18] <groz_> example, i'm already carrying openssl libs on boxes
[01:19] <groz_> so there's not a lot of overhead added to use certs
[01:19] <[Shiba]> you can't ask a user to install a 750kb application
[01:19] <[Shiba]> I haven't ever used openssl
[01:19] <[Shiba]> well directly, as a programmer that is
[01:19] <groz_> you let users install applications ???????
[01:19] <groz_> on a router ?????
[01:19] <[Shiba]> no no
[01:20] <[Shiba]> the point is that you only allow trusted applications to run
[01:20] <[Shiba]> thats the reason for hte security
[01:20] <[Shiba]> the*
[01:20] <groz_> [Shiba]: you can't ask a user to install a 750kb application
[01:20] <[Shiba]> where "trusted applications" == software for which the system administrator has seen the source code to
[01:21] <[Shiba]> no
[01:21] <[Shiba]> what I'm saying is that to use a PKCS like gpg you need to install system applications
[01:21] <[Shiba]> so it isn't feasible to use a PKCS since it consumes so much space
[01:22] <groz_> guess we see it differently, i see little/no overhead on the end boxes
[01:22] <[Shiba]> it would be very nice to have public signatures to make deployment easy
[01:22] <groz_> and, there is already an openssl based signing infrastructure in place
[01:22] <[Shiba]> hwo do you make that out?
[01:22] <[Shiba]> oh?
[01:22] <groz_> which we use for doing things like generating certs for 802.1x
[01:22] <groz_> when i do a deployment
[01:23] <[Shiba]> please fill me in, I've never done anything with openssl in my life
[01:23] <[Shiba]> well nothing big anyway
[01:23] <groz_> well my typical customers already have large networks, with certificate infrastructure already in place
[01:24] <groz_> so we just use that when we have something that 'needs certs'
[01:27] <[Shiba]> on the routers with smaller writable rom area, it isn't reasonable to force a user to install openssl
[01:27] <groz_> again, if it's already got openssl
[01:27] <[Shiba]> i.e. the wrt54g with only 2.2mb space
[01:27] <groz_> i put openssl on all my wrts
[01:28] <[Shiba]> the router I use doesn't have enough space to install openssl
[01:28] <[Shiba]> at the moment anyway
[01:28] <groz_> but, i dont let users touch them
[01:28] <[Shiba]> thats not the point
[01:28] <[Shiba]> this is specifically for system administrators, not users
[01:28] <[Shiba]> someone who would do hardware maintenance
[01:28] <groz_> again, different mindsets, you are thinking of 'other folks' updating routers
[01:28] <groz_> i deal with routers that i make specific images for
[01:28] <groz_> and have full control over every aspect of them
[01:29] <[Shiba]> no, I'm not :) -- I'm thinking of hte same people you are
[01:29] <[Shiba]> system administrators who want to configure their systems once and not more
[01:29] <groz_> so they either go out with openssl libs on board, or not
[01:29] <[Shiba]> mmm
[01:29] <groz_> hehe, well, i deal with system administrators that never configure a system, not even once
[01:29] <groz_> we flash them pre-configured
[01:29] <[Shiba]> I suppose if that is your policy, then using openssl would be ideal
[01:29] <groz_> and if there are updates, i generate new images, and we reflash them
[01:30] <groz_> so that's why i'm saying if you are going to design something new
[01:30] <groz_> do it so there is a way to plug in different mechanisms
[01:30] <groz_> to do the actual authentication
[01:30] <[Shiba]> oh, now i see what you mean
[01:31] <[Shiba]> so you would have the option of using openssl if available, and sha if not
[01:31] <[Shiba]> or something like htat
[01:31] <groz_> or even a null function do nothing if there is nothing available
[01:31] <groz_> if it's a plug architecture
[01:31] <groz_> then anything can be plugged in after the fact
[01:31] <[Shiba]> hmm so I just need to check the return value of the plugin
[01:31] <groz_> precisely
[01:32] <[Shiba]> good idea ;)
[01:32] <groz_> then, it's trivial for development
[01:32] <groz_> you start by putting in a plug that always returns ok
[01:32] <groz_> get everything else working correctly
[01:32] <groz_> now, replace the plug with one that always fails
[01:32] <groz_> confirm
[01:32] <groz_> now, rplace it again, with one that actually does something
[01:34] <[Shiba]> okay I've got a lot to think about :))
[01:34] <[Shiba]> thank you all for the input an dhelp
[01:34] <groz_> see, now if you had just gone off and gone on your own
[01:34] <groz_> you wouldn't have got all these new problems to consider
[01:35] <groz_> take a simple project, make it tuff, is easy, just ask everybody online for input on the best way to do it :)
[01:36] <[Shiba]> design phase completion: 1e-500%
[04:34] <{Nico}> Ã/win 3
[10:35] <CIA-17> florian * r4493 /packages/net/squid/ (. Config.in Makefile ipkg/): Port squid to -ng
[10:39] <CIA-17> florian * r4494 /packages/net/openser/ (. Config.in Makefile ipkg/): Port openser to -ng
[10:49] <CIA-17> florian * r4495 /packages/utils/pipacs/ (. Config.in Makefile ipkg/): Port pipacs to -ng
[10:53] <CIA-17> florian * r4496 /packages/net/portsentry/ (. Config.in Makefile ipkg/): Port portsentry to -ng
[11:00] <CIA-17> florian * r4497 /packages/net/privoxy/ (. Config.in Makefile ipkg/): Port privoxy to -ng
[11:03] <CIA-17> florian * r4498 /packages/utils/procmail/ (. Config.in Makefile ipkg/): Port procmail to -ng
[11:10] <CIA-17> florian * r4499 /packages/net/peerguardian/ (9 files in 4 dirs): Port peerguardian to -ng
[11:14] <CIA-17> florian * r4500 /packages/net/psybnc/ (. Config.in Makefile ipkg/): Port psybnc to -ng
[11:22] <CIA-17> florian * r4501 /packages/net/ptunnel/ (. Config.in Makefile ipkg/): Port ptunnel to -ng
[11:53] <CIA-17> florian * r4502 /packages/net/quagga/ (. Config.in Makefile ipkg/): Port quagga to -ng
[11:57] <CIA-17> florian * r4503 /packages/net/raddump/ (. Config.in Makefile ipkg/): Port raddump to -ng
[14:34] <CIA-17> florian * r4504 /packages/net/rarpd/ (. Config.in Makefile ipkg/): Port rarpd to -ng
[14:39] <CIA-17> florian * r4505 /packages/net/reaim/ (. Config.in Makefile ipkg/): Port reaim to -ng
[14:47] <CIA-17> florian * r4506 /packages/net/rp-l2tp/ (. Config.in Makefile ipkg/): Port rp-l2tpd to -ng
[15:26] <CIA-17> florian * r4507 /packages/net/rp-pppoe/ (. Config.in Makefile ipkg/): Port rp-pppoe to -ng
[15:31] <CIA-17> florian * r4508 /branches/buildroot-ng/openwrt/package/kernel/modules.mk: Add ieee80211softmac modules, bcm43xx, ipw2100/2200 from the kernel
[18:56] <CIA-17> florian * r4509 /packages/utils/rrdcollect/ (. Config.in Makefile ipkg/): Port rrdcollect to -ng
[19:18] <CIA-17> florian * r4510 /packages/utils/rrdtool/ (. Config.in Makefile ipkg/): Port rrdtool to -ng
[19:23] <rezso> any news on atheros front ?
[19:45] <CIA-17> florian * r4511 /packages/net/rrs/ (. Config.in Makefile ipkg/): Port rrs to -ng
[23:34] <CIA-17> nbd * r4512 /branches/buildroot-ng/openwrt/package/kernel/modules.mk: fix typo
[23:50] <{Nico}> nbd: ping
[23:52] <nbd> pong
[23:52] <groz_> splat
[23:52] <common> nbd?
[23:52] <nbd> yes?
[23:52] <common> news about Kaloz xscale patches?
[23:52] <nbd> he ported them to buildroot-ng, but no ethernet yet
[23:53] <common> commited?
[23:53] <nbd> yes
[23:53] <{Nico}> nbd: hey, how's the camp going?
[23:53] <nbd> great. it's fun
[23:53] <nbd> are you going to come?
[23:53] <groz_> nbd, you at summer camp ?
[23:53] <common> xscale compiles and boots on buildroot-ng?
[23:53] <nbd> groz_: wireless community camp - ccc, freifunk, etc.
[23:53] <{Nico}> nbd: not sure yet, probably not :(
[23:54] <nbd> common: it should
[23:54] <groz_> oh, i bet that is fun
[23:54] <nbd> it is
[23:54] <{Nico}> nbd: you said it will last till 20th iirc
[23:55] <common> nbd i'll give it a got
[23:55] <common> go
[23:55] <nbd> {Nico}: yes
[23:55] <{Nico}> nbd: will you stay till the end?
[23:55] <nbd> maybe
[23:55] <nbd> probably
[23:56] <{Nico}> will [mbm] come?
[23:57] <nbd> maybe he can make it
[23:57] <nbd> no idea
[23:57] <nbd> bug him :)
[23:57] <groz_> where is it ?
[23:57] <nbd> near hamburg
[23:57] <groz_> hmmm
[23:57] <{Nico}> nbd: i will if i can make it myself :)
[23:57] <nbd> :)
[23:57] Action: groz_ calls customer to suggest they need me to visit a client on site over there
[23:57] <groz_> we have a large client in munich
[23:58] <nbd> nice
[23:59] <{Nico}> nbd: can you a short usage on gen_busybox_menuconfig.pl?
[23:59] <nbd> hmm... don't remember. let me look it up :)
[00:00] --- Tue Aug 8 2006
[00:11] <[Shiba]> ure -- if submitted as a patch under the gpl -- would be committed?
[00:13] <[Shiba]> Please keep in mind that I am not asking the OpenWRT developers to do the work for me. I plan to write the application myself and make the necessary modifications to the openwrt rc5 tree, then submit the patch
[00:14] <[Shiba]> if there is no interest, or if said application will never be considered for inclusion, please let me know so I don't waste me time.
[00:14] <[Shiba]> my*
[00:40] <nbd> [Shiba]: it can be added as an optional package if you design it that way and don't touch base system scripts
[00:41] <nbd> [Shiba]: but you should consider writing it for buildroot-ng
[00:42] <nbd> [Shiba]: are you going to use the application yourself or is this just an idea that you had?
[00:48] <db90h> it's hard to encourage people to code for the buildroot-ng tree when it's so far from being widely deployed..
[00:48] <[Shiba]> well it is in response to a specific need of mine
[00:48] <[Shiba]> I don't actually need the higher level of functionality that a security-enabled autorun system would provide
[00:48] <[Shiba]> but to be acceptable for deployment, it needs to be secure
[00:49] <[Shiba]> and it just occurred to me that even if a script is signed properly, that doesn't mean it won't do nasty things
[00:49] <[Shiba]> like maybe a signed script is copied onto another device and the applications it calls are modified or replaced
[00:49] <nbd> you don't actually need to make the package for buildroot-ng directly
[00:50] <nbd> but you should consider using its scripts for config handling
[00:50] <nbd> in buildroot-ng, we want to have every system config file in the same format
[00:50] <nbd> at least for all services where it makes sense
[00:50] <[Shiba]> well I was thinking of adding it as a patch
[00:50] <[Shiba]> see this would complement the hotplug daemon
[00:50] <nbd> you don't need to change the base files at all
[00:51] <[Shiba]> it is inserted into the hotplug scripts
[00:51] <nbd> you can make it a package that installs scripts into /etc/hotplug.d
[00:51] <[Shiba]> well I suppose I could write it as a system daemon
[00:51] <[Shiba]> ah
[00:51] <nbd> no need to do a daemon either
[00:51] <nbd> put it in /etc/hotplug.d/<type>
[00:52] <[Shiba]> what sort of configuration file would I need to build?
[00:52] <[Shiba]> I was thinking that I would keep it simple, one hash per line
[00:52] <nbd> well, you want to have a config file that contains the signatures and other checks for files, right?
[00:52] <[Shiba]> yes
[00:53] <nbd> the config file format is grouped into sections and options
[00:53] <nbd> it looks like this
[00:53] <[Shiba]> hmmm I think I would probably need to have it scan the shell script for references to executable files and store their hashes too
[00:53] <nbd> config <section type> [<section name>]
[00:54] <nbd> option <name> <value>
[00:54] <[Shiba]> like the X config eh?
[00:54] <nbd> similar
[00:54] <nbd> but this format is very easy to parse in shell
[00:54] <nbd> it's flexible enough
[00:55] <nbd> and we have shell/awk code for manipulating these config files as well
[00:55] <[Shiba]> why didn't you go with xml?
[00:55] <db90h> wouldn't be as easy to parse, that's for sure
[00:55] <nbd> i wanted something simple
[00:56] <nbd> something that can be read by stupid shell code with no effort
[00:56] <[Shiba]> mmm good point
[00:56] <groz_> xml = sure fired way to add tons of bloat to a simple concept
[00:56] <db90h> how many packages use this new config format as of now?
[00:56] <nbd> db90h: network config and wireless config
[00:56] <db90h> hmm
[00:56] <db90h> i didn't know u guys had got that far
[00:57] <[Shiba]> is there some sort of "RFC" for this config format, or at leasta complete specification I can read?
[00:57] <db90h> boy it'd be easy to make shell or http based configurators with this
[00:57] <nbd> [Shiba]: no documentation yet, unfortunately
[00:57] <groz_> if you are truely paranoid about scripts etc being modified, why not just build your image with 'final configuration' in it, and then dont pivot onto a writeable file system
[00:57] <groz_> now your scripts are locked, and permanently locked
[00:57] <[Shiba]> well thats not the point
[00:58] <[Shiba]> I want to build a system that allows autorun from external media
[00:58] <[Shiba]> say you have some data you want to make available on nfs from the media
[00:58] <[Shiba]> you'd be able to plug the disk in and have it automagically add the config to /etc/exports when it was plugged in
[00:58] <[Shiba]> then restart the nfs daemons
[00:58] <[Shiba]> all without direct user intervention
[00:59] <[Shiba]> of course then you'd have the problem of removing said shares when the device was unplugged
[00:59] <[Shiba]> but thats something I'll have to find a way to deal with
[01:00] <groz_> hotplug is ur friend
[01:00] <[Shiba]> well yes I know
[01:00] <[Shiba]> but when hte media is unplugged, the possibility to read scripts to remove its shares from the media is gone
[01:00] <[Shiba]> perhaps I could create some sort of temp file describing what was done in /tmp
[01:01] <[Shiba]> the idea is to make a secure autorun available for usb media
[01:01] <[Shiba]> of course you don't want autorun to execute malicious code, so there have to be checks in place
[01:02] <[Shiba]> which is why I'm considering using sha256 for application signatures
[01:02] <db90h> so if the autorun scripts are signed for secuirity, who authenticates the signer? is there user prompting?
[01:02] <[Shiba]> well none of the autorun scripts get executed unless their signatures are stored on flash rom
[01:02] <[Shiba]> the user has to set it up initially
[01:02] <db90h> oh, ok, so a pre-included list of valid sigs
[01:02] <groz_> use certificates, and, pre-load the box with the 'allwed signer' certs
[01:02] <[Shiba]> yes
[01:03] <[Shiba]> but that presents another problem
[01:03] <[Shiba]> using the signed script on another media and replacing called executables with different ones
[01:03] <[Shiba]> so I have to think about how to address that
[01:04] <nbd> i wrote a small example for you that shows how the config stuff works
[01:04] <nbd> http://pastebin.ca/119648
[01:04] <[Shiba]> thank you
[01:04] <nbd> oh, wait
[01:04] <nbd> there's a typo in there
[01:05] <nbd> http://pastebin.ca/119650
[01:05] <nbd> the functions are not in the whiterussian tree yet, but will be added soon
[01:05] <nbd> i mean the config_* functions
[01:05] <[Shiba]> okay
[01:05] <nbd> when you define config_cb() and option_cb(), they are used as 'callbacks' for sections and options
[01:06] <nbd> so you can have your script process the configuration options interactively if you want
[01:06] <nbd> but you can also use the config_get function to process them at a later time
[01:06] <[Shiba]> ah, nice
[01:07] <[Shiba]> I could script most of the interface using ash, and just use sha256sum to verify signatures
[01:07] <groz_> will config_set() re-write the files :)
[01:07] <nbd> config_set doesn't change the files
[01:07] <groz_> lol
[01:07] <[Shiba]> I was thinking I would have to parse the config file in C but tha tmay be unnecessary
[01:07] <nbd> i have a separate script for that
[01:08] <nbd> config_set only changes the config state in the environment
[01:08] Action: groz_ hunts around for a 'yet'
[01:08] <nbd> [Shiba]: it is unnecessary
[01:08] <[Shiba]> yes it would be nice to just use getenv()
[01:10] <nbd> this config stuff is so easy and fast enough, because it simply defines the shell functions config() and option() and then includes the config file as shell code :)
[01:10] <nbd> no need to write a custom parser when the shell already does what you need :)
[01:10] <[Shiba]> thats nice
[01:12] <[Shiba]> but this isn't available in rc5
[01:12] <[Shiba]> which is really a bummer :((
[01:12] <nbd> i can add the functions to svn tonight
[01:12] <[Shiba]> when is rc6 due?
[01:12] <nbd> and then you can just copy over your modified functions.sh
[01:12] <[Shiba]> oh that would be nice
[01:12] <nbd> and rc6 will be released very soon
[01:13] <[Shiba]> yes please include the parsing routines in rc6 ;)
[01:14] <[Shiba]> does anyone know offhand if gpg is available in WR?
[01:14] <[Shiba]> that would make it dead simple to add hashing to files ;)
[01:15] <groz_> if it's not, should be rather trivial to add no ?
[01:15] <[Shiba]> well yes, but there is space to consider
[01:15] <[Shiba]> the gpg binary on my system is 783kb
[01:16] <[Shiba]> thats a lot to ask a user to install for autorun functionality
[01:16] <CIA-17> nbd * r4492 /branches/whiterussian/openwrt/package/base-files/default/etc/functions.sh: add config parsing functions from buildroot-ng to whiterussian
[01:16] <nbd> :)
[01:16] <[Shiba]> niiiiice
[01:16] <[Shiba]> thank you nbd!
[01:17] <[Shiba]> hmm so it may be worth it to use sha256 instead of a PKCS due to space constraints
[01:18] <[Shiba]> considering that I can get an sha256 implementation that consumes less than 40kb uncompressed
[01:18] <nbd> makes sense
[01:18] <groz_> if you are going to do it, make it flexible
[01:18] <groz_> example, i'm already carrying openssl libs on boxes
[01:19] <groz_> so there's not a lot of overhead added to use certs
[01:19] <[Shiba]> you can't ask a user to install a 750kb application
[01:19] <[Shiba]> I haven't ever used openssl
[01:19] <[Shiba]> well directly, as a programmer that is
[01:19] <groz_> you let users install applications ???????
[01:19] <groz_> on a router ?????
[01:19] <[Shiba]> no no
[01:20] <[Shiba]> the point is that you only allow trusted applications to run
[01:20] <[Shiba]> thats the reason for hte security
[01:20] <[Shiba]> the*
[01:20] <groz_> [Shiba]: you can't ask a user to install a 750kb application
[01:20] <[Shiba]> where "trusted applications" == software for which the system administrator has seen the source code to
[01:21] <[Shiba]> no
[01:21] <[Shiba]> what I'm saying is that to use a PKCS like gpg you need to install system applications
[01:21] <[Shiba]> so it isn't feasible to use a PKCS since it consumes so much space
[01:22] <groz_> guess we see it differently, i see little/no overhead on the end boxes
[01:22] <[Shiba]> it would be very nice to have public signatures to make deployment easy
[01:22] <groz_> and, there is already an openssl based signing infrastructure in place
[01:22] <[Shiba]> hwo do you make that out?
[01:22] <[Shiba]> oh?
[01:22] <groz_> which we use for doing things like generating certs for 802.1x
[01:22] <groz_> when i do a deployment
[01:23] <[Shiba]> please fill me in, I've never done anything with openssl in my life
[01:23] <[Shiba]> well nothing big anyway
[01:23] <groz_> well my typical customers already have large networks, with certificate infrastructure already in place
[01:24] <groz_> so we just use that when we have something that 'needs certs'
[01:27] <[Shiba]> on the routers with smaller writable rom area, it isn't reasonable to force a user to install openssl
[01:27] <groz_> again, if it's already got openssl
[01:27] <[Shiba]> i.e. the wrt54g with only 2.2mb space
[01:27] <groz_> i put openssl on all my wrts
[01:28] <[Shiba]> the router I use doesn't have enough space to install openssl
[01:28] <[Shiba]> at the moment anyway
[01:28] <groz_> but, i dont let users touch them
[01:28] <[Shiba]> thats not the point
[01:28] <[Shiba]> this is specifically for system administrators, not users
[01:28] <[Shiba]> someone who would do hardware maintenance
[01:28] <groz_> again, different mindsets, you are thinking of 'other folks' updating routers
[01:28] <groz_> i deal with routers that i make specific images for
[01:28] <groz_> and have full control over every aspect of them
[01:29] <[Shiba]> no, I'm not :) -- I'm thinking of hte same people you are
[01:29] <[Shiba]> system administrators who want to configure their systems once and not more
[01:29] <groz_> so they either go out with openssl libs on board, or not
[01:29] <[Shiba]> mmm
[01:29] <groz_> hehe, well, i deal with system administrators that never configure a system, not even once
[01:29] <groz_> we flash them pre-configured
[01:29] <[Shiba]> I suppose if that is your policy, then using openssl would be ideal
[01:29] <groz_> and if there are updates, i generate new images, and we reflash them
[01:30] <groz_> so that's why i'm saying if you are going to design something new
[01:30] <groz_> do it so there is a way to plug in different mechanisms
[01:30] <groz_> to do the actual authentication
[01:30] <[Shiba]> oh, now i see what you mean
[01:31] <[Shiba]> so you would have the option of using openssl if available, and sha if not
[01:31] <[Shiba]> or something like htat
[01:31] <groz_> or even a null function do nothing if there is nothing available
[01:31] <groz_> if it's a plug architecture
[01:31] <groz_> then anything can be plugged in after the fact
[01:31] <[Shiba]> hmm so I just need to check the return value of the plugin
[01:31] <groz_> precisely
[01:32] <[Shiba]> good idea ;)
[01:32] <groz_> then, it's trivial for development
[01:32] <groz_> you start by putting in a plug that always returns ok
[01:32] <groz_> get everything else working correctly
[01:32] <groz_> now, replace the plug with one that always fails
[01:32] <groz_> confirm
[01:32] <groz_> now, rplace it again, with one that actually does something
[01:34] <[Shiba]> okay I've got a lot to think about :))
[01:34] <[Shiba]> thank you all for the input an dhelp
[01:34] <groz_> see, now if you had just gone off and gone on your own
[01:34] <groz_> you wouldn't have got all these new problems to consider
[01:35] <groz_> take a simple project, make it tuff, is easy, just ask everybody online for input on the best way to do it :)
[01:36] <[Shiba]> design phase completion: 1e-500%
[04:34] <{Nico}> Ã/win 3
[10:35] <CIA-17> florian * r4493 /packages/net/squid/ (. Config.in Makefile ipkg/): Port squid to -ng
[10:39] <CIA-17> florian * r4494 /packages/net/openser/ (. Config.in Makefile ipkg/): Port openser to -ng
[10:49] <CIA-17> florian * r4495 /packages/utils/pipacs/ (. Config.in Makefile ipkg/): Port pipacs to -ng
[10:53] <CIA-17> florian * r4496 /packages/net/portsentry/ (. Config.in Makefile ipkg/): Port portsentry to -ng
[11:00] <CIA-17> florian * r4497 /packages/net/privoxy/ (. Config.in Makefile ipkg/): Port privoxy to -ng
[11:03] <CIA-17> florian * r4498 /packages/utils/procmail/ (. Config.in Makefile ipkg/): Port procmail to -ng
[11:10] <CIA-17> florian * r4499 /packages/net/peerguardian/ (9 files in 4 dirs): Port peerguardian to -ng
[11:14] <CIA-17> florian * r4500 /packages/net/psybnc/ (. Config.in Makefile ipkg/): Port psybnc to -ng
[11:22] <CIA-17> florian * r4501 /packages/net/ptunnel/ (. Config.in Makefile ipkg/): Port ptunnel to -ng
[11:53] <CIA-17> florian * r4502 /packages/net/quagga/ (. Config.in Makefile ipkg/): Port quagga to -ng
[11:57] <CIA-17> florian * r4503 /packages/net/raddump/ (. Config.in Makefile ipkg/): Port raddump to -ng
[14:34] <CIA-17> florian * r4504 /packages/net/rarpd/ (. Config.in Makefile ipkg/): Port rarpd to -ng
[14:39] <CIA-17> florian * r4505 /packages/net/reaim/ (. Config.in Makefile ipkg/): Port reaim to -ng
[14:47] <CIA-17> florian * r4506 /packages/net/rp-l2tp/ (. Config.in Makefile ipkg/): Port rp-l2tpd to -ng
[15:26] <CIA-17> florian * r4507 /packages/net/rp-pppoe/ (. Config.in Makefile ipkg/): Port rp-pppoe to -ng
[15:31] <CIA-17> florian * r4508 /branches/buildroot-ng/openwrt/package/kernel/modules.mk: Add ieee80211softmac modules, bcm43xx, ipw2100/2200 from the kernel
[18:56] <CIA-17> florian * r4509 /packages/utils/rrdcollect/ (. Config.in Makefile ipkg/): Port rrdcollect to -ng
[19:18] <CIA-17> florian * r4510 /packages/utils/rrdtool/ (. Config.in Makefile ipkg/): Port rrdtool to -ng
[19:23] <rezso> any news on atheros front ?
[19:45] <CIA-17> florian * r4511 /packages/net/rrs/ (. Config.in Makefile ipkg/): Port rrs to -ng
[23:34] <CIA-17> nbd * r4512 /branches/buildroot-ng/openwrt/package/kernel/modules.mk: fix typo
[23:50] <{Nico}> nbd: ping
[23:52] <nbd> pong
[23:52] <groz_> splat
[23:52] <common> nbd?
[23:52] <nbd> yes?
[23:52] <common> news about Kaloz xscale patches?
[23:52] <nbd> he ported them to buildroot-ng, but no ethernet yet
[23:53] <common> commited?
[23:53] <nbd> yes
[23:53] <{Nico}> nbd: hey, how's the camp going?
[23:53] <nbd> great. it's fun
[23:53] <nbd> are you going to come?
[23:53] <groz_> nbd, you at summer camp ?
[23:53] <common> xscale compiles and boots on buildroot-ng?
[23:53] <nbd> groz_: wireless community camp - ccc, freifunk, etc.
[23:53] <{Nico}> nbd: not sure yet, probably not :(
[23:54] <nbd> common: it should
[23:54] <groz_> oh, i bet that is fun
[23:54] <nbd> it is
[23:54] <{Nico}> nbd: you said it will last till 20th iirc
[23:55] <common> nbd i'll give it a got
[23:55] <common> go
[23:55] <nbd> {Nico}: yes
[23:55] <{Nico}> nbd: will you stay till the end?
[23:55] <nbd> maybe
[23:55] <nbd> probably
[23:56] <{Nico}> will [mbm] come?
[23:57] <nbd> maybe he can make it
[23:57] <nbd> no idea
[23:57] <nbd> bug him :)
[23:57] <groz_> where is it ?
[23:57] <nbd> near hamburg
[23:57] <groz_> hmmm
[23:57] <{Nico}> nbd: i will if i can make it myself :)
[23:57] <nbd> :)
[23:57] Action: groz_ calls customer to suggest they need me to visit a client on site over there
[23:57] <groz_> we have a large client in munich
[23:58] <nbd> nice
[23:59] <{Nico}> nbd: can you a short usage on gen_busybox_menuconfig.pl?
[23:59] <nbd> hmm... don't remember. let me look it up :)
[00:00] --- Tue Aug 8 2006