CardBus Support
Hi, any idea on how to enable CardBus Support on 5.6 ? i'm getting this message on boot related to the PCMCIA card that i'm trying to use on my old toshiba lapto, the card works just fine under pfsense/freebsd Dmesg: cbb0 at pci1 dev 4 function 0 "ENE CB-1410 CardBus" rev 0x01: apic 1 int 16, CardBus support disabled cardslot0 at cbb0 slot 0 flags 0 Any help please.
Re: standard FAQ procedure ... in chroot
On Sun, Jun 8, 2014 at 12:16 PM, Janne Johansson wrote:
> It feels like you are trying to convince someone that
> chroot("/");
> equals not being chrooted at all.
Not at all. I'm trying to convince someone to explain what chrooted
means, preferably without changing current semantics.
chroot(2), for instance, doesn't mention the term "alternate root
directory" as a well-defined state that includes--but does not limit
itself to--the invoking process' root directory, nor does chroot(2)
reference or allude to the "creation" of an "alternate root
directory".
Am I supposed to consider mknod(2)'s wording authoritative over chroot(2)'s?
Maybe the first step is recognizing that the documentation is unclear
on the subject.
>
> In my view several things happen when a pid is started in a chroot,
> including
> 1. the dir used as a parameter for the chroot will always be its own parent
> dir so that you may never again go above it. You may (haven't checked)
> chroot yourself lower again, but not "stop" the chroot.
> 2. You may not create device nodes since that would make it easy to defeat
> the chroot if root.
>
> This list may be far longer, but I don't think the docs need fixing for the
> chroot("/"); case when mknod:ing.
>
>
>
> 2014-06-08 17:44 GMT+02:00 Andres Perera :
>
>> On Sun, Jun 8, 2014 at 3:51 AM, Otto Moerbeek wrote:
>> > On Sun, Jun 08, 2014 at 02:59:08AM -0430, Andres Perera wrote:
>> >
>> >> On Sun, Jun 8, 2014 at 2:24 AM, Janne Johansson
>> wrote:
>> >> > I don't think there is a word for "chroot back".
>> >>
>> >> I don't think you read, understood, and executed the sample.
>> >>
>> >> After chroot("/"), or chroot(FOO), you can't mknod(2), therefore the
>> >> description is wrong.
>> >
>> > What part is wrong?
>> >
>> > "alternate" directory might happen to be / itself.
>>
>> Even though it's the same directory as the previous root directory?
>>
>> How is it alternate, then?
>>
>> What's alternating, other than the root directory, which is *the same*?
>>
>> Either make this fd_rdir check a string comparison in addition to a
>> null-pointer check or change the docs instead of being confusing:
>>
>> int
>> domknodat(struct proc *p, int fd, const char *path, mode_t mode, dev_t dev)
>> {
>> struct vnode *vp;
>> struct vattr vattr;
>> int error;
>> struct nameidata nd;
>>
>> if ((error = suser(p, 0)) != 0)
>> return (error);
>> if (p->p_fd->fd_rdir)
>> return (EINVAL);
>>
>>
>> While that's silly
>> > to do it's still an alternate to an unchrooted /.
>> >
>> > -Otto
>> >
>>
>
>
>
> --
> May the most significant bit of your life be positive.
Re: standard FAQ procedure ... in chroot
On Sun, Jun 8, 2014 at 3:51 AM, Otto Moerbeek wrote:
> On Sun, Jun 08, 2014 at 02:59:08AM -0430, Andres Perera wrote:
>
>> On Sun, Jun 8, 2014 at 2:24 AM, Janne Johansson wrote:
>> > I don't think there is a word for "chroot back".
>>
>> I don't think you read, understood, and executed the sample.
>>
>> After chroot("/"), or chroot(FOO), you can't mknod(2), therefore the
>> description is wrong.
>
> What part is wrong?
>
> "alternate" directory might happen to be / itself.
Even though it's the same directory as the previous root directory?
How is it alternate, then?
What's alternating, other than the root directory, which is *the same*?
Either make this fd_rdir check a string comparison in addition to a
null-pointer check or change the docs instead of being confusing:
int
domknodat(struct proc *p, int fd, const char *path, mode_t mode, dev_t dev)
{
struct vnode *vp;
struct vattr vattr;
int error;
struct nameidata nd;
if ((error = suser(p, 0)) != 0)
return (error);
if (p->p_fd->fd_rdir)
return (EINVAL);
While that's silly
> to do it's still an alternate to an unchrooted /.
>
> -Otto
Re: standard FAQ procedure ... in chroot
On Sun, Jun 8, 2014 at 2:24 AM, Janne Johansson wrote:
> I don't think there is a word for "chroot back".
I don't think you read, understood, and executed the sample.
After chroot("/"), or chroot(FOO), you can't mknod(2), therefore the
description is wrong.
Once you limit yourself
> into a chroot, you are stuck in it and get special treatment until you
> exit. Apart from why mknod wants to fail inside chroots, having a simple
> syscall being able to take you out of it would defeat the whole purpose, no?
>
>
>
> 2014-06-08 4:36 GMT+02:00 Andres Perera :
>
>> The description of EINVAL in mknod(2) is wrong:
>>
>> [EINVAL] The process is running within an alternate root
>> directory, as created by chroot(2).
>>
>> Even if a process chroot()s back to /, it can't create a device node.
>>
>> The program below exits with EINVAL:
>>
>> #include
>> #include
>>
>> int main() {
>> chroot("/");
>> if (mknod("/t", 0x21b6, 0x1600) == -1) /* stdin amd64 */
>> err(1, "mknod");
>> }
>>
>> On Sat, Jun 7, 2014 at 2:42 PM, Miod Vallat wrote:
>> >> >> Is this some kind of security protection ?
>> >> >
>> >> > of course... see mknod(2).
>> >>
>> >> i read it and still does not understand.
>> >
>> > Check the description of EINVAL.
>>
>>
>
>
> --
> May the most significant bit of your life be positive.
Re: standard FAQ procedure ... in chroot
The description of EINVAL in mknod(2) is wrong:
[EINVAL] The process is running within an alternate root
directory, as created by chroot(2).
Even if a process chroot()s back to /, it can't create a device node.
The program below exits with EINVAL:
#include
#include
int main() {
chroot("/");
if (mknod("/t", 0x21b6, 0x1600) == -1) /* stdin amd64 */
err(1, "mknod");
}
On Sat, Jun 7, 2014 at 2:42 PM, Miod Vallat wrote:
>> >> Is this some kind of security protection ?
>> >
>> > of course... see mknod(2).
>>
>> i read it and still does not understand.
>
> Check the description of EINVAL.
Re: pkg_add http://${REDIRECT}
On Mon, Apr 28, 2014 at 3:05 PM, Michał Lesiak wrote:
> Hello,
>
> I'm trying to invent a oneliner for installing a specific package. The
> problem is, the destination file is a redirect file forwarding a request to
> a target package. The result is:
>
> # pkg_add -v
> http://10bees-agent.s3-website-us-east-1.amazonaws.com/openbsd/agent.tgz
> parsing agent
> Package name is not consistent ???
> Error from
> http://10bees-agent.s3-website-us-east-1.amazonaws.com/openbsd/agent.tgz
> Redirected to
> http://10bees-agent.s3-website-us-east-1.amazonaws.com/openbsd/10bees-1.1.55.20.tgz
> ftp: Writing -: Broken pipe
> --- 10bees-1.1.55.20 ---
> Can't install 10bees-1.1.55.20: bad package
>
> The idea behind that is that 'agent.tgz' will always point to the latest
> version, so there is no need for users to keep track of the versions.
Given package name-version{0,1}.tgz in a $PKG_PATH directory, `pkg_add
name` will match both and present the user with a choice.
Given package name-version1.tgz only, `pkg_add name` doesn't prompt
because there's a single directory entry match.
I would exclusively populate the directory with entries, symlinks or
otherwise, pertaining to the latest version of packages.
Re: sudo -u & environment help
On Tue, Apr 8, 2014 at 7:17 AM, Andres Perera wrote:
> On Fri, Apr 4, 2014 at 6:00 AM, Craig R. Skinner
> wrote:
>> Hi,
>>
>> When sudo'ing to another user, how can I obtain all of their environment
>> settings as they receive when logging in themselves?
>>
>> When I use sudo in this manner, settings such as $PATH, $MAIL & umask
>> aren't being honoured:
>
> [...]
>
> You do that with `sudo -c - -l`:
>
> $ { ulimit -a; env; } > ea
> $ sudo -c - -i 'ulimit -a; env' > eb
> $ diff -u ea e
> --- ea Tue Apr 8 07:13:11 2014
> +++ eb Tue Apr 8 07:14:22 2014
> @@ -1,29 +1,24 @@
> time(cpu-seconds)unlimited
> file(blocks) unlimited
> coredump(blocks) unlimited
> -data(kbytes) 524288
> -stack(kbytes)4096
> +data(kbytes) 33554432
> +stack(kbytes)8192
> lockedmem(kbytes)2667916
> memory(kbytes) 7984356
> -nofiles(descriptors) 512
> -processes128
> +nofiles(descriptors) 128
> +processes1310
> _=/usr/bin/env
> +USERNAME=root
> XAUTHORITY=/home/a/.Xauthority
> -LOGNAME=a
> -WINDOWID=10485773
> -WINDOWPATH=5
> -XTERM_SHELL=/usr/bin/tmux
> -HOME=/home/a
> -PWD=/home/a
> -XTERM_VERSION=XTerm/OpenBSD(301)
> +LOGNAME=root
> +HOME=/root
> +SUDO_GID=1000
> DISPLAY=:0
> +SUDO_COMMAND=/bin/ksh -c ulimit -a; env
> +SUDO_USER=a
> +SUDO_UID=1000
> MAIL=/var/mail/a
^ the fact that $MAIL is preserved is a bug according to sudo(8),
section ``Command Environment'':
As a special case, if sudo's -i option (initial login) is specified, sudo
will initialize the environment regardless of the value of env_reset.
The DISPLAY, PATH and TERM variables remain unchanged; HOME, MAIL, SHELL,
USER, and LOGNAME are set based on the target user.
As shown, $MAIL doesn't correspond to the target user, which in this
invocation would be root.
> -PATH=/home/a/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.
> -TMUX=/tmp/tmux-1000/default,3104,0
> -PAGER=less
> -TMUX_PANE=%2
> -TERM=screen
> +PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
> SHELL=/bin/ksh
> -DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-8X6HB7BfTU,guid=b24ea188864417630554661f5343d7bf
> -USER=a
> -XTERM_LOCALE=C
> +TERM=screen
> +USER=root
>
> Also see `use_loginclass` in sudoers(5).
Re: sudo -u & environment help
On Fri, Apr 4, 2014 at 6:00 AM, Craig R. Skinner
wrote:
> Hi,
>
> When sudo'ing to another user, how can I obtain all of their environment
> settings as they receive when logging in themselves?
>
> When I use sudo in this manner, settings such as $PATH, $MAIL & umask
> aren't being honoured:
[...]
You do that with `sudo -c - -l`:
$ { ulimit -a; env; } > ea
$ sudo -c - -i 'ulimit -a; env' > eb
$ diff -u ea e
--- ea Tue Apr 8 07:13:11 2014
+++ eb Tue Apr 8 07:14:22 2014
@@ -1,29 +1,24 @@
time(cpu-seconds)unlimited
file(blocks) unlimited
coredump(blocks) unlimited
-data(kbytes) 524288
-stack(kbytes)4096
+data(kbytes) 33554432
+stack(kbytes)8192
lockedmem(kbytes)2667916
memory(kbytes) 7984356
-nofiles(descriptors) 512
-processes128
+nofiles(descriptors) 128
+processes1310
_=/usr/bin/env
+USERNAME=root
XAUTHORITY=/home/a/.Xauthority
-LOGNAME=a
-WINDOWID=10485773
-WINDOWPATH=5
-XTERM_SHELL=/usr/bin/tmux
-HOME=/home/a
-PWD=/home/a
-XTERM_VERSION=XTerm/OpenBSD(301)
+LOGNAME=root
+HOME=/root
+SUDO_GID=1000
DISPLAY=:0
+SUDO_COMMAND=/bin/ksh -c ulimit -a; env
+SUDO_USER=a
+SUDO_UID=1000
MAIL=/var/mail/a
-PATH=/home/a/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.
-TMUX=/tmp/tmux-1000/default,3104,0
-PAGER=less
-TMUX_PANE=%2
-TERM=screen
+PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
SHELL=/bin/ksh
-DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-8X6HB7BfTU,guid=b24ea188864417630554661f5343d7bf
-USER=a
-XTERM_LOCALE=C
+TERM=screen
+USER=root
Also see `use_loginclass` in sudoers(5).
Re: dead disk
On Tue, Jan 28, 2014 at 6:12 AM, Philip Guenther wrote: > On Tue, Jan 28, 2014 at 2:03 AM, Andres Perera wrote: >> On Tue, Jan 28, 2014 at 4:55 AM, Philip Guenther wrote: > ... >>> I'm no expert on softdeps, so maybe you have a better explanation for >>> why Kirk made the choice he did to have it panic in some cases? >> >> well, i'm no expert either. now that we have presented our >> credentials, let's go back to what was already conjecture > ... >> do you want the kernel to figure these out after the fact and >> retroactively panic() for each occurence, neatly queueing them boot >> after boot or do you want to grow a pair of balls instead? > > You ignore my pointer to the actual engineering and logic in this area > and prefer to expand upon the conjecture. I cannot help in that area > and am unwilling to have you reorder my TODO list to suit your > pleasure. > the comments pertain to your misrepresentation of McKusick's softdep paper. this being a public forum, your todo list is your personal business, and in any case not for others to be shoehorned into when blatant mistakes need correction the paper does not support the notion that metadata cache flushing failures lead to complete system instability meriting a panic. quote the relevant text or stop pretending that it's there. meanwhile, there are cases where synchronous writing of metadata can also allow the unavailability and corruption of a previously succesful system call's pervasive effects. the onus is on you, or in your imaginary representation of the paper, to prove that halting the system is justifiable in BOTH circumstances. the paper does not discuss alternatives, eg, mounting read only and preserving references to unflushed data until unmount... so thread along if you find looking for a solution uninteresting. that's better than lying. > Instead I look forward to your diff fixing this bug in softdeps. > Please send that diff to the list and not me directly, as I find your > submissions uninteresting. > > > Philip Guenther
Re: dead disk
On Tue, Jan 28, 2014 at 4:55 AM, Philip Guenther wrote: > On Tue, Jan 28, 2014 at 12:27 AM, Andres Perera wrote: >> On Sun, Jan 26, 2014 at 5:07 PM, Philip Guenther wrote: >>> On Sun, Jan 26, 2014 at 11:40 AM, emigrant wrote: >>>> My Master machine is dead, exactly HDD(thank you God for CARP+pfsync) :). >>>> >>>> root@master[/etc]wd0(pciide0:0:0): timeout >>>> type: ata >>>> c_bcount: 16384 >>>> c_skip: 0 >>> ... >>>> /: got error 5 while accessing filesystem >>>> panic: softdep_deallocate_dependencies: unrecovered I/O error >>>> Stopped at Debugger+0x4: popl%ebp >>>> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! >>>> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! >>>> ddb> >>> >>> This is a fundamental problem of softdeps:it can delay an operation to >>> a point where other operations depend on it in a such a way that if >>> the I/O for that first operation fails, the dependent operations >>> cannot be undone and the failure propagated up safely. Rather than >>> live a lie, it'll panic the system and die. >> >> the way the decision to panic() was stated implies that the course of >> action is justified, when detaching the disk/hub, or forcefully >> mounting it read only, are alternatives that could be explored. > > How do those alternative actions, which can only fail in-progress and > future operation, satisfactorily resolve the case of operations WHICH > HAVE ALREADY RETURNED SUCCESS but whose effects will actually be lost > and not durable? > > I'm no expert on softdeps, so maybe you have a better explanation for > why Kirk made the choice he did to have it panic in some cases? well, i'm no expert either. now that we have presented our credentials, let's go back to what was already conjecture do you understand that disks have write caches that don't give a hoot about posix mkdir() rename() and so on? can bit rot change a inode type from directory to file, and vice versa? do you want the kernel to figure these out after the fact and retroactively panic() for each occurence, neatly queueing them boot after boot or do you want to grow a pair of balls instead? > > > Philip Guenther
Re: dead disk
On Sun, Jan 26, 2014 at 5:07 PM, Philip Guenther wrote: > On Sun, Jan 26, 2014 at 11:40 AM, emigrant wrote: >> My Master machine is dead, exactly HDD(thank you God for CARP+pfsync) :). >> >> root@master[/etc]wd0(pciide0:0:0): timeout >> type: ata >> c_bcount: 16384 >> c_skip: 0 > ... >> /: got error 5 while accessing filesystem >> panic: softdep_deallocate_dependencies: unrecovered I/O error >> Stopped at Debugger+0x4: popl%ebp >> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! >> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! >> ddb> > > This is a fundamental problem of softdeps:it can delay an operation to > a point where other operations depend on it in a such a way that if > the I/O for that first operation fails, the dependent operations > cannot be undone and the failure propagated up safely. Rather than > live a lie, it'll panic the system and die. the way the decision to panic() was stated implies that the course of action is justified, when detaching the disk/hub, or forcefully mounting it read only, are alternatives that could be explored the other day I unplugged the power connector from a malfunctioning DVD-RW drive that was being too darn noisy. the kernel proceeded to detach the ahci device hosting the aformentioned drive and an sd with mounted ffs partitions i could've unplugged the power connector in the middle of a string of metadata writes to the sd. does that entail that the system should panic? hopefully the current outcome will remain, because it's way more useful than my pc throwing a hissy's fits. > > I don't know exactly which operations can lead to that; if you need to > know that you should go read the softdeps papers on Kirk McKusick's > site. > > > Philip Guenther
Re: Request for Funding our Electricity
On Wed, Jan 15, 2014 at 2:44 PM, Peter J. Philipp wrote: > On 01/15/14 19:41, Martin Schröder wrote: >> 2014/1/15 Sia Lang : >>> That small donation wouldn't have amounted to much, but I am positive you >>> being the leader of this project is the very reason no one wants to step up >>> with serious funding. >> >> Him being the leader is the very reason this project still exists. > > I agree on that. Theo is not only a good programmer he is also a > business man and has successfully sold his product. > > Since everyone has ideas, I want to put up another small idea of mine. > When people donate even if it's $15 it's worth something, and we who > donate are all appreciative of any amount given by peers. So then if > 20,000 dollars is 365 days for electricity how about OpenBSD chops > everyones donation into a timeslot. Every package built with the ports > system at that timeslot then displays whose time it was that finalised > the package. So if my time was used it would say: > > # pkg_add somepackage > ... > This package's buildtime was generously donated by Peter J. Philipp. until libre office takes ~30 $50 dollar donations, bombarding my terminal with names of insecure ppl > # > > or > > # pkg_add someotherpackage > ... > This package's buildtime was generously donated by Scary Corporation. > # > > The programming for this is probably the least of worries, OpenBSD has > after all a bunch of coders. The other aspect is that it's advertising, > but it's not too intrusive in my view, and it does honor the little guy > too as his timeslot may build X amount of packages. > > People want to feel that they get something back so perhaps > cross-referencing can be done who did what packages buildtime and that > can be tracked back. It's advertising that particular person, making > them feel a bond towards the project and they will likely donate again, > to relive that feel. > > It's just an idea, > > Cheers, > > -peter
Re: resolver question
On Thu, Dec 26, 2013 at 6:09 AM, Peter J. Philipp wrote: > On 12/24/13 22:08, Andres Perera wrote: >> i think further investigation is due on OP's part > > OK. I first removed the domain keyword out of the /etc/resolv.conf and > updated /etc/resolv.conf.tail. > > Then I stuck "search centroid.eu" in there instead so that it looked > like this: > > > # Generated by re0 dhclient > search centroid.eu > nameserver 192.168.34.1 > search centroid.eu > lookup file bind > family inet6 inet4 > > > I turned up logs on the immediate nameserver (192.168.34.1) and watched > them a bit. Here is what I then read: > > Dec 26 11:17:31 uranus named[12220]: client 192.168.34.4#22419: query: > www.spiegel.de.centroid.eu IN + > > so the "leak" I described earlier was happening here too. it would be easier if you work on isolating why is this happening; don't worry about interim servers and other variables, just configure a machine with a nameserver running on localhost while trying to sort this out > Then I adjusted the search keyword to only do "search ." and that > stopped the leak, however it still created 2 queries where one would > suffice: > > > # Generated by re0 dhclient > search centroid.eu > nameserver 192.168.34.1 > search . > lookup file bind > family inet6 inet4 > > > queries were: > > Dec 26 11:27:54 uranus named[12220]: client 192.168.34.4#38177: query: > www.spiegel.de IN + > Dec 26 11:27:54 uranus named[12220]: client 192.168.34.4#24662: query: > www.spiegel.de IN + > > So reasonable, just as I want them. Too bad there is 2 of the same, so > it's not exactly perfect. what browser are you using? how is it calling resolver(3) routines? it seems strange that the cache would allow for two identical queries in such a short time span (both on the same second, 11:27:54) > > I'm wondering if this hint can be included into the resolv.conf manpage > somehow, something like: > > > "search ." stops leaking quad-A queries to the domain's nameserver. > > > But I'm looking for proper wording and place to put it into the manpage. > > Thanks, > > -peter
Re: resolver question
On Tue, Dec 24, 2013 at 3:50 PM, Andy Bradford wrote: > Thus said "Peter J. Philipp" on Tue, 24 Dec 2013 17:33:10 +: > >> I was browsing http://chealth.canoe.ca when I saw the above log. I'm >> supposing the resolver looks up chealth.canoe.ca, and then eventually >> does a lookup for chealth.canoe.ca.centroid.eu. centroid.eu is the >> domain I configured in resolv.conf by means of DHCP. > > You have a some options: > > 1) Change your habits to use a fully qualified domain name; e.g., a > domain name that ends with a final/trailing dot. chealth.cano.ca is > ambiguous (perhaps not in your brain, but to a computer, it doesn't know > that you really mean chealth.canoe.ca. which is absolute). So use > http://chealth.canoe.ca./ (note the trailing dot). > 2) Don't configure a search option in /etc/resolv.conf as each domain > listed in the search is appended to the query in order. E.g., if > you have centroid.eu and google.com in your search, then your DNS > resolver will take chealth.canoe.ca and append centroid.eu., attempt to > resolve it but fail. Then it will take chealth.canoe.ca and append > google.com., attempt to resolve it but fail, and then finally it will > try chealth.canoe.ca., attempt to resolve it and receive a successful > response. the suffix list may still be initialized from the ``domain'' keyword, which is very likely in a dhcp scenario, and more than that, present in the OP dhcp-fed resolv.conf thus setting ``search .'' is the way of insuring that no suffixes be appended, even when ``domain'' is present, or when ``domain'' is absent and it's consequently deduced from the system hostname what's interesting is that the query has more than the default ndots i think further investigation is due on OP's part > Andy > -- > TAI64 timestamp: 400052b9ecb0
Re: resolver question
On Tue, Dec 24, 2013 at 1:03 PM, Peter J. Philipp wrote: > On Tue, Dec 24, 2013 at 10:25:06AM -0500, Kenneth R Westerback wrote: >> On Mon, Dec 23, 2013 at 02:37:47PM +0100, Peter J. Philipp wrote: >> > I'm trying to track down the code in the libasr that causes this behaviour: >> > >> > Whenever I go to a IPv4 site and IPv6 query is made for domain+mydomain >> > like a search. So with logging turned on, on my nameserver I get this: >> > >> > pjp@americas$ grep canoe.ca.centroid.eu /var/log/all >> > Dec 20 17:00:37 americas wildcarddnsd[29850]: request on descriptor 17 >> > interface "em0" from 212.114.242.132 (ttl=54, region=255) for >> > "chealth.canoe.ca.centroid.eu." type=(28) class=1, answering "NXDOMAIN" >> > >> > The problem is that my nameservers are in china and latin america and >> > I'M sorta worried about these leaks. This particular log came from my >> > nameserver in panama and the packet passes miami. >> >> I'm not clear on what the leak you are worried about is. >> >> Ken > > Hi Ken, Merry Christmas! > > I was browsing http://chealth.canoe.ca when I saw the above log. I'm > supposing > the resolver looks up chealth.canoe.ca, and then eventually does a lookup for > chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in > resolv.conf by means of DHCP. a FQDN ends with a period this tells a correctly functioning dns subsystem--"correctly" being subject to your willingness to abide a collection of rfcs, all the way from local binaries to remote hosts[0]--that you wish to resolve that name sans transformations the ``search'' keyword in resolv.conf is a suffix that may be appended to unqualified domain names prior resolving them to ip addresses 1. check if you are really configuring the appropiate settings. some programs, eg dig, willfully ignore the search keyword by default. some browsers use their own resolvers 2. clear the ``search`` keyword: $ echo 'search .' >> /etc/resolv.conf.tail # dhclient $INTERFACE > > I'm wondering why it does that though? Someone in the US, like the NSA, can > then sit back and see my browsing habits, which I call a leak. I'm hoping on > finding the knob that turns this off. The leak wouldn't happen if my > centroid.eu nameservers were just in .de but then you can just replace NSA > with BND the german intelligence sniffers (s/NSA/BND). > > I'd really just rather replace the function that allows > chealth.canoe.ca.centroid.eu lookup to exit my DSL as all that should exit is > a lookup for just chealth.canoe.ca, which takes a different lookup path in the > Internet. > > Regards, > > -peter > >> > >> > My resolv.conf file looks like this on the workstation here in germany: >> > >> > jupiter$ more /etc/resolv.conf >> > # Generated by re0 dhclient >> > search centroid.eu >> > nameserver 192.168.34.1 >> > domain centroid.eu >> > lookup file bind >> > family inet6 inet4 >> > >> > >> > The leak only happens with queries, like said. Any hints on >> > tracking this down and squelching it? >> > >> > Regards, >> > >> > -peter
Re: Are there any default password managers in OpenBSD?
On Sat, Dec 7, 2013 at 2:22 PM, Christian Weisgerber wrote:
> Christian Weisgerber wrote:
>
>> --->
>> #!/bin/sh
>>
>> SAFE=$HOME/.pwsafe
>> TMPFILE=`mktemp /tmp/pwsafeXX` || exit 1
>>
>> trap 'rm -P "$TMPFILE"' 0 1 2 15
>>
>> STTY=`stty -g`
>> echo -n "Password: "
>> stty -echo
>> read PASSWORD
>> stty "$STTY"
>>
>> set -e
>> echo -n "$PASSWORD" | openssl aes-256-cbc -d -in "$SAFE" -out "$TMPFILE"
>> -pass stdin
>> ${EDITOR-${VISUAL-vi}} "$TMPFILE"
>> echo -n "$PASSWORD" | openssl aes-256-cbc -in "$TMPFILE" -out "$SAFE" -pass
>> stdin
>> <---
>
> So this stood up to review here pretty well.
i tried to set my password but changed the terminal title instead
>
> The major potential leak is that the decrypted content is temporarily
> stored as a cleartext file.
interesting. vi cant open stdin, but vim can. it seems that we are
accomodating to the limitations of sh and vi instead of recognizing
they're unsuitable
> If your storage is backed by some sort
> of log-structured filesystem, like a flash memory medium, the
> cleartext will not actually be overwritten and may be recoverable.
> Also, your editor may scatter additional cleartext copies around,
> for instance vi's recovery files.
>
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
Re: Are there any default password managers in OpenBSD?
On Sat, Dec 7, 2013 at 4:10 AM, Jan Stary wrote:
> On Dec 06 02:20:49, andre...@zoho.com wrote:
>> >> conclusion: shell is not good for this
>> >
>> > Yeah right.
>> > Who would even think of doing this in shell.
>>
>> apparently at least one person did
>
> I was being sarcastic of course, dipshit.
>
>> you aren't in sync with the quantity of real world shells that use
>> temp files for heredoc, and who feature combinations of { printf
>> (not)? being a builtin, alternatives like ``print'' and ``echo'' are
>> unportable }
>
> Indeed, I am not in sync with the quantity of real world shells
> (as opposed to sh?), thank god. Christian's code is pure sh though.
what does this even mean?
some implementations of sh use tmpfiles and some don't. this isn't
about syntax differences.
you aren't understanding the subject, but choose to participate anyways. why?
who do you think you're impressing?
>
>> >> even if it keeps heredocs in memory you have no idea if it zeros it
>> >> out afterwards
>
> Also, the letters of the password get read
> by the console driver as you type them.
> God knows what happens there.
>
> On Dec 06 08:15:19, andre...@zoho.com wrote:
>> you use cat, muffin face:
>> ...
>> STTY=`stty -g`
>> echo -n "Password: "
>> stty -echo
>> cat > PASSWORD_FILE_DONT_READ_IF_YOU_ARE_OTHER_PROCESS_PLS
>
> So after typing "password" and hitting [enter],
> you are still running that cat.
> Just what the user expects.
Re: Are there any default password managers in OpenBSD?
On Fri, Dec 6, 2013 at 8:29 AM, Paul de Weerd wrote:
> On Fri, Dec 06, 2013 at 08:15:19AM -0430, Andres Perera wrote:
> | you use cat, muffin face:
> | ...
> | STTY=`stty -g`
> | echo -n "Password: "
> | stty -echo
> | cat > PASSWORD_FILE_DONT_READ_IF_YOU_ARE_OTHER_PROCESS_PLS
> | stty "$STTY"
> | ...
> | openssl -d ... < PASSWORD_FILE_DONT_READ_IF_YOU_ARE_OTHER_PROCESS_PLS
>
> Right, so you have to send Ctrl-D too... Quite unexpected behaviour
> maybe.
1. if A is a partial set of answers that don't make for interesting
exchanges but pleases the whims, A = { head -n1, awk '{print;exit}',
perl -ne 'print;exit' }
2. unexpected to naddy or who are we talking about. not sure what the
focus is. are we tailoring the script to a particular person or is
this about creating a good tool with sh?
>
> | why did i use printf or heredoc? what happens if a password contains
> | the subtring "\r" when you echo it? does "naddy" feel comfortable with
> | the brittle dependency of echo being a builtin, and does everybody
> | else?
>
> Maybe Naddy wrote his script with his use case in mind. Could be he
> doesn't have "\r" in his password (also, printf doesn't help in that
> case, but the heredoc does)
o ok as long as it's good for naddy. feels like im sucking up to a
stranger over the wire instead of discussing the fucking script, huh
>
> Why do you think the dependency is 'brittle'? echo has been a
> built-in of /bin/sh since it was imported into OpenBSD.
>
> | why are you such a retard?
>
> Mostly to annoy you ;) Why resort to namecalling anyway? That's not
> very nice... (and an insult to retarded folks around the globe)
>
> Anyway, you win. Congrats! No need to respond to my questions (but
> no problem if you do; just know that I won't reply any further on this
> (sub-)thread).
>
> Paul 'WEiRD' de Weerd
>
> --
>>[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
> http://www.weirdnet.nl/
Re: Are there any default password managers in OpenBSD?
On Fri, Dec 6, 2013 at 8:07 AM, Paul de Weerd wrote: > On Fri, Dec 06, 2013 at 07:41:17AM -0430, Andres Perera wrote: > | On Fri, Dec 6, 2013 at 7:09 AM, Paul de Weerd wrote: > | > On Fri, Dec 06, 2013 at 06:59:02AM -0430, Andres Perera wrote: > | > | with C you can be very explicit about where you store and when you zero > out > | > > | > with shell you can be very explicit about where you store and when you > | > zero out > | > | well, > | > | instead of `read PASSWORD', the code could've stored the password in a > | file > > Oh really? How then, pray tell, would you've gotten the PASSWORD in > that file? How do you get input from the user and store it in a file, > without using read in a shell script? you use cat, muffin face: ... STTY=`stty -g` echo -n "Password: " stty -echo cat > PASSWORD_FILE_DONT_READ_IF_YOU_ARE_OTHER_PROCESS_PLS stty "$STTY" ... openssl -d ... < PASSWORD_FILE_DONT_READ_IF_YOU_ARE_OTHER_PROCESS_PLS > > | pipe it to openssl for unlocking, and rm -P that along with the > | cleartext version of the db, avoiding problems w/transporting with a > | possibly external printf that broadcasts in ps(1), or a tmpfile-backed > | heredoc > > Naddy's original post didn't use printf, it used echo. It didn't use > a tmpfile-backed heredoc, it piped in the password to openssl's stdin > using the builtin echo. You're describing problems that could've been > if Naddy had been more clumsy. But he wasn't, Naddy didn't do any of > that. > > Here's something else Naddy could've done (but didn't): He could've > put the password on a public website and used ftp -o - to pass it into > openssl. He didn't do something stupid like that. Suggesting this > and arguing against it contributes nothing. So I don't. > > You are arguing about things that didn't happen. You're not > contributing anything of value either. The problem with you is that > you think you did... why did i use printf or heredoc? what happens if a password contains the subtring "\r" when you echo it? does "naddy" feel comfortable with the brittle dependency of echo being a builtin, and does everybody else? why are you such a retard? > > | this way you are explicit, also reusing logic already present > | > | it's still clumsy way of cleartext store, and exposes the file to > | other user processes > | > | on the other hand, ptrace() means memory is exposed to other user processes > | > | so, you are still being a silly person and i don't feel like stressing > | that further > | > | > > | > | with shell it's easy to be clumsy in this particular domain > | > > | > with C it's easy to be clumsy in this particular domain > | > > | > > | > What you said is true, sure, but it also holds the other way around. > | > | what you said is like reading a book of chinese sayings; ie you > | contributed nothing > | > | > > | > Paul 'WEiRD' de Weerd > | > > | > -- > | >>[<++>-]<+++.>+++[<-->-]<.>+++[<+ > | > +++>-]<.>++[<>-]<+.--.[-] > | > http://www.weirdnet.nl/ > | > > -- >>[<++>-]<+++.>+++[<-->-]<.>+++[<+ > +++>-]<.>++[<>-]<+.--.[-] > http://www.weirdnet.nl/
Re: Are there any default password managers in OpenBSD?
mark the variable volatile or external. what you said also holds for
kernel drivers, is well known, and is much easier to understand than
shell indiosyncrasies
another silly person in conversation ~
On Fri, Dec 6, 2013 at 7:26 AM, Marios Makassikis wrote:
> On 6 December 2013 12:29, Andres Perera wrote:
>> On Fri, Dec 6, 2013 at 5:22 AM, Alexander Hall wrote:
>>> On 12/06/13 07:50, Andres Perera wrote:
>>>>
>>>> On Fri, Dec 6, 2013 at 1:58 AM, Jan Stary wrote:
>>>>>
>>>>> On Dec 05 19:09:05, andre...@zoho.com wrote:
>>>>>>
>>>>>> but then if the shell implementation uses tmpfiles for heredoc,
>>>>>
>>>>>
>>>>> does it?
>>>>
>>>>
>>>> ksh does:
>>>>
>>>> ~ $ :<>>>>
>>>>> $(sleep 100)
>>>>> !
>>>>
>>>> [1] 469
>>>> ~ $ ls /tmp/sh*
>>>> /tmp/shsWf2OXAO
>>>>
>>>> src/bin/ksh/exec.c r1.50:
>>>>
>>>> /* Create temp file to hold content (done before newenv so temp
>>>> * doesn't get removed too soon).
>>>> */
>>>> h = maketemp(ATEMP, TT_HEREDOC_EXP, &e->temps);
>>>>
>>>>>
>>>>>> and
>>>>>> doesn't do the equivalent of rm -P, you have another leak you thought
>>>>>> was taken care of
>>>>>>
>>>>>> conclusion: shell is not good for this
>>>>>
>>>>>
>>>>> Yeah right.
>>>>> Who would even think of doing this in shell.
>>>>
>>>>
>>>> apparently at least one person did
>>>>
>>>> you aren't in sync with the quantity of real world shells that use
>>>> temp files for heredoc, and who feature combinations of { printf
>>>> (not)? being a builtin, alternatives like ``print'' and ``echo'' are
>>>> unportable }
>>>>
>>>
>>> You do point out some interesting apects. I've used the heredoc approach
>>> without considering if my shell used tempfiles or not, but I'm usually
>>> mostly concerned about stuff not going on the command line.
>>>
>>> However one decides for onself where to draw the line. There are probably
>>> tons of leaks, even if you write your own code.
>>>
>>> X, xterm, vi, clipboard, ...
>>
>> yes, but this case is particularly insidious because i noticed that
>> the original code went through the trouble of rm -P
>>
>> some people may have tmp as a memory backed fs and decide their uptime
>> longevity is short enough, some people may have their entire fs's
>> encrypted and decide that's enough
>>
>> that doesn't change the fact that modern password handling code
>> doesn't transitively store cleartext secrets this way
>>
>> with C you can be very explicit about where you store and when you zero out
>>
>
> That does not mean this is going to happen though. Did you just
> bzero() or memset()
> a buffer where you had stored sensitive data ? It may not be enough. From the
> compiler's point of view If you don't use the buffer afterwards, then
> there is no to
> call bzero() at all, so the call may be suppressed as part of optimisations.
>
>
>> with shell it's easy to be clumsy in this particular domain
>>
>>>
>>> /Alexander
>>>
>>>
>>>>>
>>>>>> even if it keeps heredocs in memory you have no idea if it zeros it
>>>>>> out afterwards
>>>>>>
>>>>>> On Thu, Dec 5, 2013 at 6:57 PM, Andres Perera wrote:
>>>>>>>
>>>>>>> On Thu, Dec 5, 2013 at 8:57 AM, Christian Weisgerber
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Zé Loff wrote:
>>>>>>>>
>>>>>>>>> Not sure how advisable this is, but I'm using a gpg encrypted file,
>>>>>>>>> which I keep somewhere hidden (just because). Just put them in file
>>>>>>>>> foo and do 'gpg -e foo' (assuming you've already setup gpg). When you
>>>>>>>>> need to look something up just do 'gpg -d foo' and the file gets
>>>>>>>>> decrypted to stdout.
>>>>>>>>
>>>>>>>>
>>>>>>>> *takes a deep breath*
>>>>>>>>
>>>>>>>> ~/bin/pwsafe
>>>>>>>> --->
>>>>>>>> #!/bin/sh
>>>>>>>>
>>>>>>>> SAFE=$HOME/.pwsafe
>>>>>>>> TMPFILE=`mktemp /tmp/pwsafeXX` || exit 1
>>>>>>>>
>>>>>>>> trap 'rm -P "$TMPFILE"' 0 1 2 15
>>>>>>>>
>>>>>>>> STTY=`stty -g`
>>>>>>>> echo -n "Password: "
>>>>>>>> stty -echo
>>>>>>>> read PASSWORD
>>>>>>>> stty "$STTY"
>>>>>>>>
>>>>>>>> set -e
>>>>>>>> echo -n "$PASSWORD" | openssl aes-256-cbc -d -in "$SAFE" -out
>>>>>>>> "$TMPFILE" -pass stdin
>>>>>>>
>>>>>>>
>>>>>>> this is tricky. some people will read and say ok i'll switch echo for
>>>>>>> printf and get on w/my life
>>>>>>>
>>>>>>> printf not being a builtin, will show up in ps(1), and so will
>>>>>>> $PASSWORD
>>>>>>>
>>>>>>> not apparent from the simple syntax used that such a change could end
>>>>>>> up leaking important things
>>>>>>>
>>>>>>> it's better to use heredoc:
>>>>>>>
>>>>>>> openssl aes-256-cbc -d -in "$SAFE" -out "$TMPFILE" -pass stdin <>>>>>> $PASSWORD
>>>>>>> !
>>>>>>>
>>>>>>>> ${EDITOR-${VISUAL-vi}} "$TMPFILE"
>>>>>>>> echo -n "$PASSWORD" | openssl aes-256-cbc -in "$TMPFILE" -out "$SAFE"
>>>>>>>> -pass stdin
>>>>>>>> <---
>>>>>>>>
>>>>>>>> --
>>>>>>>> Christian "naddy" Weisgerber
>>>>>>>> na...@mips.inka.de
Re: Are there any default password managers in OpenBSD?
On Fri, Dec 6, 2013 at 7:09 AM, Paul de Weerd wrote: > On Fri, Dec 06, 2013 at 06:59:02AM -0430, Andres Perera wrote: > | with C you can be very explicit about where you store and when you zero out > > with shell you can be very explicit about where you store and when you > zero out well, instead of `read PASSWORD', the code could've stored the password in a file, pipe it to openssl for unlocking, and rm -P that along with the cleartext version of the db, avoiding problems w/transporting with a possibly external printf that broadcasts in ps(1), or a tmpfile-backed heredoc this way you are explicit, also reusing logic already present it's still clumsy way of cleartext store, and exposes the file to other user processes on the other hand, ptrace() means memory is exposed to other user processes so, you are still being a silly person and i don't feel like stressing that further > > | with shell it's easy to be clumsy in this particular domain > > with C it's easy to be clumsy in this particular domain > > > What you said is true, sure, but it also holds the other way around. what you said is like reading a book of chinese sayings; ie you contributed nothing > > Paul 'WEiRD' de Weerd > > -- >>[<++>-]<+++.>+++[<-->-]<.>+++[<+ > +++>-]<.>++[<>-]<+.--.[-] > http://www.weirdnet.nl/
Re: Are there any default password managers in OpenBSD?
On Fri, Dec 6, 2013 at 5:22 AM, Alexander Hall wrote:
> On 12/06/13 07:50, Andres Perera wrote:
>>
>> On Fri, Dec 6, 2013 at 1:58 AM, Jan Stary wrote:
>>>
>>> On Dec 05 19:09:05, andre...@zoho.com wrote:
>>>>
>>>> but then if the shell implementation uses tmpfiles for heredoc,
>>>
>>>
>>> does it?
>>
>>
>> ksh does:
>>
>> ~ $ :<>>
>>> $(sleep 100)
>>> !
>>
>> [1] 469
>> ~ $ ls /tmp/sh*
>> /tmp/shsWf2OXAO
>>
>> src/bin/ksh/exec.c r1.50:
>>
>> /* Create temp file to hold content (done before newenv so temp
>> * doesn't get removed too soon).
>> */
>> h = maketemp(ATEMP, TT_HEREDOC_EXP, &e->temps);
>>
>>>
>>>> and
>>>> doesn't do the equivalent of rm -P, you have another leak you thought
>>>> was taken care of
>>>>
>>>> conclusion: shell is not good for this
>>>
>>>
>>> Yeah right.
>>> Who would even think of doing this in shell.
>>
>>
>> apparently at least one person did
>>
>> you aren't in sync with the quantity of real world shells that use
>> temp files for heredoc, and who feature combinations of { printf
>> (not)? being a builtin, alternatives like ``print'' and ``echo'' are
>> unportable }
>>
>
> You do point out some interesting apects. I've used the heredoc approach
> without considering if my shell used tempfiles or not, but I'm usually
> mostly concerned about stuff not going on the command line.
>
> However one decides for onself where to draw the line. There are probably
> tons of leaks, even if you write your own code.
>
> X, xterm, vi, clipboard, ...
yes, but this case is particularly insidious because i noticed that
the original code went through the trouble of rm -P
some people may have tmp as a memory backed fs and decide their uptime
longevity is short enough, some people may have their entire fs's
encrypted and decide that's enough
that doesn't change the fact that modern password handling code
doesn't transitively store cleartext secrets this way
with C you can be very explicit about where you store and when you zero out
with shell it's easy to be clumsy in this particular domain
>
> /Alexander
>
>
>>>
>>>> even if it keeps heredocs in memory you have no idea if it zeros it
>>>> out afterwards
>>>>
>>>> On Thu, Dec 5, 2013 at 6:57 PM, Andres Perera wrote:
>>>>>
>>>>> On Thu, Dec 5, 2013 at 8:57 AM, Christian Weisgerber
>>>>> wrote:
>>>>>>
>>>>>> Zé Loff wrote:
>>>>>>
>>>>>>> Not sure how advisable this is, but I'm using a gpg encrypted file,
>>>>>>> which I keep somewhere hidden (just because). Just put them in file
>>>>>>> foo and do 'gpg -e foo' (assuming you've already setup gpg). When you
>>>>>>> need to look something up just do 'gpg -d foo' and the file gets
>>>>>>> decrypted to stdout.
>>>>>>
>>>>>>
>>>>>> *takes a deep breath*
>>>>>>
>>>>>> ~/bin/pwsafe
>>>>>> --->
>>>>>> #!/bin/sh
>>>>>>
>>>>>> SAFE=$HOME/.pwsafe
>>>>>> TMPFILE=`mktemp /tmp/pwsafeXX` || exit 1
>>>>>>
>>>>>> trap 'rm -P "$TMPFILE"' 0 1 2 15
>>>>>>
>>>>>> STTY=`stty -g`
>>>>>> echo -n "Password: "
>>>>>> stty -echo
>>>>>> read PASSWORD
>>>>>> stty "$STTY"
>>>>>>
>>>>>> set -e
>>>>>> echo -n "$PASSWORD" | openssl aes-256-cbc -d -in "$SAFE" -out
>>>>>> "$TMPFILE" -pass stdin
>>>>>
>>>>>
>>>>> this is tricky. some people will read and say ok i'll switch echo for
>>>>> printf and get on w/my life
>>>>>
>>>>> printf not being a builtin, will show up in ps(1), and so will
>>>>> $PASSWORD
>>>>>
>>>>> not apparent from the simple syntax used that such a change could end
>>>>> up leaking important things
>>>>>
>>>>> it's better to use heredoc:
>>>>>
>>>>> openssl aes-256-cbc -d -in "$SAFE" -out "$TMPFILE" -pass stdin <>>>> $PASSWORD
>>>>> !
>>>>>
>>>>>> ${EDITOR-${VISUAL-vi}} "$TMPFILE"
>>>>>> echo -n "$PASSWORD" | openssl aes-256-cbc -in "$TMPFILE" -out "$SAFE"
>>>>>> -pass stdin
>>>>>> <---
>>>>>>
>>>>>> --
>>>>>> Christian "naddy" Weisgerber
>>>>>> na...@mips.inka.de
Re: Are there any default password managers in OpenBSD?
On Fri, Dec 6, 2013 at 1:58 AM, Jan Stary wrote:
> On Dec 05 19:09:05, andre...@zoho.com wrote:
>> but then if the shell implementation uses tmpfiles for heredoc,
>
> does it?
ksh does:
~ $ :< $(sleep 100)
> !
[1] 469
~ $ ls /tmp/sh*
/tmp/shsWf2OXAO
src/bin/ksh/exec.c r1.50:
/* Create temp file to hold content (done before newenv so temp
* doesn't get removed too soon).
*/
h = maketemp(ATEMP, TT_HEREDOC_EXP, &e->temps);
>
>> and
>> doesn't do the equivalent of rm -P, you have another leak you thought
>> was taken care of
>>
>> conclusion: shell is not good for this
>
> Yeah right.
> Who would even think of doing this in shell.
apparently at least one person did
you aren't in sync with the quantity of real world shells that use
temp files for heredoc, and who feature combinations of { printf
(not)? being a builtin, alternatives like ``print'' and ``echo'' are
unportable }
>
>> even if it keeps heredocs in memory you have no idea if it zeros it
>> out afterwards
>>
>> On Thu, Dec 5, 2013 at 6:57 PM, Andres Perera wrote:
>> > On Thu, Dec 5, 2013 at 8:57 AM, Christian Weisgerber
>> > wrote:
>> >> Zé Loff wrote:
>> >>
>> >>> Not sure how advisable this is, but I'm using a gpg encrypted file,
>> >>> which I keep somewhere hidden (just because). Just put them in file
>> >>> foo and do 'gpg -e foo' (assuming you've already setup gpg). When you
>> >>> need to look something up just do 'gpg -d foo' and the file gets
>> >>> decrypted to stdout.
>> >>
>> >> *takes a deep breath*
>> >>
>> >> ~/bin/pwsafe
>> >> --->
>> >> #!/bin/sh
>> >>
>> >> SAFE=$HOME/.pwsafe
>> >> TMPFILE=`mktemp /tmp/pwsafeXX` || exit 1
>> >>
>> >> trap 'rm -P "$TMPFILE"' 0 1 2 15
>> >>
>> >> STTY=`stty -g`
>> >> echo -n "Password: "
>> >> stty -echo
>> >> read PASSWORD
>> >> stty "$STTY"
>> >>
>> >> set -e
>> >> echo -n "$PASSWORD" | openssl aes-256-cbc -d -in "$SAFE" -out "$TMPFILE"
>> >> -pass stdin
>> >
>> > this is tricky. some people will read and say ok i'll switch echo for
>> > printf and get on w/my life
>> >
>> > printf not being a builtin, will show up in ps(1), and so will $PASSWORD
>> >
>> > not apparent from the simple syntax used that such a change could end
>> > up leaking important things
>> >
>> > it's better to use heredoc:
>> >
>> > openssl aes-256-cbc -d -in "$SAFE" -out "$TMPFILE" -pass stdin <> > $PASSWORD
>> > !
>> >
>> >> ${EDITOR-${VISUAL-vi}} "$TMPFILE"
>> >> echo -n "$PASSWORD" | openssl aes-256-cbc -in "$TMPFILE" -out "$SAFE"
>> >> -pass stdin
>> >> <---
>> >>
>> >> --
>> >> Christian "naddy" Weisgerber na...@mips.inka.de
Re: Are there any default password managers in OpenBSD?
but then if the shell implementation uses tmpfiles for heredoc, and
doesn't do the equivalent of rm -P, you have another leak you thought
was taken care of
conclusion: shell is not good for this
even if it keeps heredocs in memory you have no idea if it zeros it
out afterwards
On Thu, Dec 5, 2013 at 6:57 PM, Andres Perera wrote:
> On Thu, Dec 5, 2013 at 8:57 AM, Christian Weisgerber
> wrote:
>> Zé Loff wrote:
>>
>>> Not sure how advisable this is, but I'm using a gpg encrypted file,
>>> which I keep somewhere hidden (just because). Just put them in file
>>> foo and do 'gpg -e foo' (assuming you've already setup gpg). When you
>>> need to look something up just do 'gpg -d foo' and the file gets
>>> decrypted to stdout.
>>
>> *takes a deep breath*
>>
>> ~/bin/pwsafe
>> --->
>> #!/bin/sh
>>
>> SAFE=$HOME/.pwsafe
>> TMPFILE=`mktemp /tmp/pwsafeXX` || exit 1
>>
>> trap 'rm -P "$TMPFILE"' 0 1 2 15
>>
>> STTY=`stty -g`
>> echo -n "Password: "
>> stty -echo
>> read PASSWORD
>> stty "$STTY"
>>
>> set -e
>> echo -n "$PASSWORD" | openssl aes-256-cbc -d -in "$SAFE" -out "$TMPFILE"
>> -pass stdin
>
> this is tricky. some people will read and say ok i'll switch echo for
> printf and get on w/my life
>
> printf not being a builtin, will show up in ps(1), and so will $PASSWORD
>
> not apparent from the simple syntax used that such a change could end
> up leaking important things
>
> it's better to use heredoc:
>
> openssl aes-256-cbc -d -in "$SAFE" -out "$TMPFILE" -pass stdin < $PASSWORD
> !
>
>> ${EDITOR-${VISUAL-vi}} "$TMPFILE"
>> echo -n "$PASSWORD" | openssl aes-256-cbc -in "$TMPFILE" -out "$SAFE" -pass
>> stdin
>> <---
>>
>> --
>> Christian "naddy" Weisgerber na...@mips.inka.de
Re: Are there any default password managers in OpenBSD?
On Thu, Dec 5, 2013 at 8:57 AM, Christian Weisgerber wrote:
> Zé Loff wrote:
>
>> Not sure how advisable this is, but I'm using a gpg encrypted file,
>> which I keep somewhere hidden (just because). Just put them in file
>> foo and do 'gpg -e foo' (assuming you've already setup gpg). When you
>> need to look something up just do 'gpg -d foo' and the file gets
>> decrypted to stdout.
>
> *takes a deep breath*
>
> ~/bin/pwsafe
> --->
> #!/bin/sh
>
> SAFE=$HOME/.pwsafe
> TMPFILE=`mktemp /tmp/pwsafeXX` || exit 1
>
> trap 'rm -P "$TMPFILE"' 0 1 2 15
>
> STTY=`stty -g`
> echo -n "Password: "
> stty -echo
> read PASSWORD
> stty "$STTY"
>
> set -e
> echo -n "$PASSWORD" | openssl aes-256-cbc -d -in "$SAFE" -out "$TMPFILE"
> -pass stdin
this is tricky. some people will read and say ok i'll switch echo for
printf and get on w/my life
printf not being a builtin, will show up in ps(1), and so will $PASSWORD
not apparent from the simple syntax used that such a change could end
up leaking important things
it's better to use heredoc:
openssl aes-256-cbc -d -in "$SAFE" -out "$TMPFILE" -pass stdin < ${EDITOR-${VISUAL-vi}} "$TMPFILE"
> echo -n "$PASSWORD" | openssl aes-256-cbc -in "$TMPFILE" -out "$SAFE" -pass
> stdin
> <---
>
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
Re: Blocking facebook.com: PF or squid?
Regards, The way it gets blocked (but not all for a wise kid) properly is via CDIR and block DNS via OpenDNS services Greetings. 2013/10/18 Stefan Wollny > Hi there, > > having a personal dislike of Facebook (and the MeeToo-systems alike) > for their impertinent sniffing for private data I tried on my laptop to > block facebook.com via hosts-file. Interestingly this failed: Calling > "http://www.facebook.com"; always resulted in a lookup for > "httpS://www.facebook.com" and the respective site showed up in the > browser (tried firefox and xombrero). > > Well: Beside excepting the fact that those facebook engineers did a > fine job circumventing the entrys in /etc/hosts I felt immediatly > insecure: The reports on this company's attitude towards even > non-customers privacy are legendary. Their respective track record > earns them the honorable title of "NSA's fittest supporter"... > > Anyway: I think I finally managed to block all their IPs via PF and on > this laptop I now feel a little less 'observed'. [Yes, I know - this is > just today's snapshot of IPs!] > > My question is on the squid-server I have running at home: What > would make more sense - blocking facebook.com via pf.conf alike or are > there reasons to use squid's ACL instead? Performance? Being > ultra-paranoid and implementing both (or even additionally the > hosts-file-block?)? From my understanding squid should not be able to > block https-traffic as it is encrypted - or am I wrong here? > > Curious if there is a particular (Open)BSD solution or simply how you > 'guys and gals' would do it. > > Thank you for sharing your thoughts. > > Cheers, > STEFAN > > -- Atentamente Andrés Genovez Tobar / DTIT Perfil profesional http://lnkd.in/gcdhJE
PF+ALTQ and real time monitoring
Hi, can anyone tell me the best or at least the most used real time bandwith monitoring tool, when using the PF+ALTQ solution please? thanks in advance.
Re: Man page that explains the file format of man pages?
he's not talking about the source level mandoc/man macros the subject is about the SYNOPSIS section language for utilities e.g. in ``grep [ file ]'' the [ ] operator signifies 0 or 1 in ``rm file...'' the ... operator signifies 1 or more On Tue, Aug 13, 2013 at 2:58 AM, Jan Stary wrote: >> On Mon, Aug 12, 2013 at 9:21 PM, Anthony J. Bentley wrote: >> > Evan Root writes: >> > > Hello Misc, >> > > I tried man 5 man for an explanation of the synopsis section of the man >> > > page and it says there isn't a manual for the file format conventions of >> > > manual pages. Sometimes I have difficulty with the syntax of the synopsis >> > > sections, is there a document I can refer to? >> > >> > OpenBSD manuals are written in the mdoc macro language. There is a page >> > describing it, in section 7 (not 5). It is mentioned in the "SEE ALSO" >> > section of man(1). >> > >> > man 7 mdoc >> > >> > There is also a man(7) page, describing the older "man" macros, but these >> > are not used for new manuals in OpenBSD. mdoc has the advantage of being >> > a semantic format, unlike the old man language where the commands mostly >> > change only the presentation. > > On Aug 12 22:19:58, cellarr...@gmail.com wrote: >> I don't think you understood. I am not looking to write a man page. I was >> just wondering if the system came with an explanation of the manual page >> synopsis section language syntax. > > Which is exactly what Anthony pointed you to: > The mdoc(7) describes the language syntax in great detail. > >> Sometimes I get confused by the language >> and am not sure if I understand the synopsis sections of the man pages. >> Also I am concerned that people who I might recommend OpenBSD to will find >> that an undocumented part of the system is the man pages. > > The mandoc people could probably take this as an offence. > The manual system, as other parts of OpenBSD, is thoroughly documented. > >> Even the welcome message from Theo says "This message attempts to describe >> the most basic initial questions that a >> system administrator of an OpenBSD box might have. If you are not >> familiar with how to read man pages, type >> "man man" at a shell prompt and read the entire thing." > > Well have you? That points you to mdoc(7) in SEE ALSO. > > "How to read man pages" in the welcome message refers > to the the rendered manpages - as presented to the user with man(1). > You are asking about the language syntax - how the manpages are written. > >> I think that this post on stack exchange presents my question better.. the >> answers are all pretty short and non-committal though. >> http://stackoverflow.com/questions/8716047/is-there-a-specification-for-a-man-pages-synopsis-section > > So you _are_ looking to write a manpage; > mdoc(7) has a section called "MANUAL STRUCTURE" > with a subsection called "SYNOPIS". Have you missed it? > > After you write it, don't forget to 'mandoc -Tlint'.
Re: Man page that explains the file format of man pages?
On Mon, Aug 12, 2013 at 11:49 PM, Evan Root wrote: > I think that this post on stack exchange presents my question better.. the > answers are all pretty short and non-committal though. > http://stackoverflow.com/questions/8716047/is-there-a-specification-for-a-man-pages-synopsis-section the best answer is included in that stack exchange submission POSIX.1-2008 Chapter 12 "Utility Conventions" describes the syntax of the SYNOPSIS sections for utilities, which is what you're looking for
Re: Default software in the base
On Thu, Aug 1, 2013 at 8:47 AM, wrote: > Almost forgot to say about this vttest thing. Um, you do realize that it's > been written by the author of XTerm? that does not imply bias. you're coming off as ignorant > And how it is XTerm-specific? and these are xterm replacements. they are emulating xterm, just like any modern "terminal" emulator i think you haven't looked into these applications in the least
Re: Default software in the base
when st or a similarly small project passes a test for vim, emacs, mutt, other popular ncurses clients, then it's worth thinking about replacing xterm in absence of such test, settle for vttest, which also tests for features that aren't as widely used something like an xterm replacement needs to show such results... i can't imagine a sane alternative On Wed, Jul 31, 2013 at 12:01 PM, wrote: > Stuart Henderson wrote: > >> On 2013-07-29, h...@riseup.net wrote: >> > URXVT >> > * The code base is half the size of XTerm's >> >> given that you have to include things like glib, gettext and iconv in this, >> somehow I doubt this... >> >> $ pkg_info -S rxvt-unicode >> Information for inst:rxvt-unicode-9.18 >> >> Signature: >> rxvt-unicode-9.18,@gdk-pixbuf-2.28.2p1,@gettext-0.18.2p2,@libiconv-1.14p0,@startup-notification-0.12p0,X11.15.2,Xft.8.0,Xrender.5.0,c.68.4,fontconfig.8.0,gdk_pixbuf-2.0.2800.0,glib-2.0.3600.1,gobject-2.0.3600.1,iconv.6.0,intl.6.0,m.8.0,perl.13.0,pthread.17.3,startup-notification-1.2.0,util.11.5 > These are optional dependencies, it can be compiled without them given you do > this by hand. > A minimal installation doesn't require any gtk libs, neither it does gettext, > iconv or perl. Most of > the bloat is hidden inside the xterm which includes support for ancient DEC > terminals (do you > have one? let's swap the emulator with it, 'cause it's a "real thing"!); > direct dependence > on the X toolkit, large codebase of about 75.000 lines of code that lasts > since '84 - that's > almost 30 years! The problem, of course, is not with age actually. Unix rolls > its history since the > 60s and there are no competitors even on the horizon. It's not about amount > of code either - look > at vim, for instance. The problem is that this code in those 30 years has > transformed in a series > of unclear hacks here and there. And like in happened with the GCC the > resulted architecture simply > slows the monster down year by year. > > Those things became evident not even now as the original rxvt project was > started over 20 years ago. > There's st as well, which is BSD-licenced, not GPL. With only one dependency. > > > All right, people, just don't get mad on my proclaimations after all...
Re: Default software in the base
On Mon, Jul 29, 2013 at 2:18 PM, wrote: > Hello @misc, > > I am yet another interested in provided OpenBSD defaults. More > specifically the XTerm and GCC. Apparently there are better alternatives > like: > > URXVT > > * The code base is half the size of XTerm's > * Consumes 25% less memory > * Can be daemonized > * Much better handling of different fonts and unicode > * Supports all the fancy features XTerm does like > 256 colours/transparency/etc > > st > > * the code base is very small and clean, pure C > * thus it can be reviewed fast security-wise > * consumes 60% less memory (than XTerm) > * the license is BSD > * most of the important features are still here both of which are more or less crappy xterm (not vt100, not vt220) emulators why not just settle for the real thing? do you want to import vte crap aswell?? > > On the other hand XTerm is an old code and memory hog that relies on X > toolkit and supports features you'll find nowhere thus will never need > (like Tektronix).
Re: Handling nested partition mounts with NFS (/usr/src)
to complete what i said, you *should* be able to mount /usr and then /usr/src, so yes that indeed seems like crazy things in windows however you also had another expectation (which i also had when starting with nfs): that nfs mounting /usr would recursively mount contained exports On Fri, Jul 5, 2013 at 10:10 PM, Nathan Goings wrote: > On 7/5/2013 7:33 PM, Andres Perera wrote: >> >> you want nested nfs mounts which nfsv3/2 can't provide >> >> the export is associated to the mount point, it won't cross device limits >> >> either put /usr/src in the same file system, or use another nfs host > > > Thanks! I think for now, I'll just export /usr/src/sys so I can work on > this driver. > > However, it's odd that I can't mount both (starting with /usr). I'm not > sure if that's a limitation for NFS or NFS client services for Windows.
Re: tmux and Shift+Return combination
according to key_string_set_modifiers() in key-string.c, :bind-key -n s-enter send-key enter On Fri, Jul 5, 2013 at 9:13 PM, patrick keshishian wrote: > On Fri, Jul 5, 2013 at 5:56 PM, patrick keshishian wrote: >> On Fri, Jul 5, 2013 at 5:52 PM, Nicholas Marriott >> wrote: >>> Ok so Return and Shift-Return never did anything different, you are just >>> wondering why Shift-Return no longer sends the same as Return. >>> >>> This is because tmux now treats it as a separate key by turning on the >>> xterm modifyOtherKeys feature. This means you can bind Return and >>> Shift-Return separately in tmux itself. The extended keys are also sent >>> through to applications inside tmux if the xterm-keys option is turned >>> on. > > To get the old behavior back, I should do something resembling: > > :bind-key -n Shift+Enter send-key Enter > > If so, I'm not quit getting how to specify the Shift+Return/Enter > combination. tmux complains about "unknown key". > > help? :) > > --patrick > > >> So... is there anyway I can enable the old behavior? I scanned through >> the tmux man page prior to my initial post, didn't see anything >> obvious. I'll go re-read again, but if there is a quick hint you can >> offer, that would be appreciated! >> >> --patrick >> >> >>> >>> >>> On Fri, Jul 05, 2013 at 05:28:58PM -0700, patrick keshishian wrote: Hi, On Fri, Jul 5, 2013 at 5:07 PM, Nicholas Marriott wrote: > What did Shift-Return used to send? Run cat outside tmux and tell me > what it shows when you press Shift-Return. Not sure what you mean by running "cat outside tmux". Running `hexdump -C' (within xterm) shows 0a sent with Return and Shift+Return: $ hexdump -C RET-> 52 45 54 2d 3e 0a |RET->.| 0006 $ hexdump -C SHIFT+RET-> 53 48 49 46 54 2b 52 45 54 2d 3e 0a |SHIFT+RET->.| 000c Is that similar to what you were asking for? --patrick > On Fri, Jul 05, 2013 at 03:42:39PM -0700, patrick keshishian wrote: >> Hi, >> >> Was running 2013-FEB-12 amd64 snapshot. Installed 2013-JUN-27 amd64 >> snapshot a couple of days ago. >> >> Immediately noticed that Shift+Return combination isn't being sent to >> the shell. I can't quite tell where/when this changed. Any ideas? >> >> --patrick
Re: Handling nested partition mounts with NFS (/usr/src)
you want nested nfs mounts which nfsv3/2 can't provide the export is associated to the mount point, it won't cross device limits either put /usr/src in the same file system, or use another nfs host On Fri, Jul 5, 2013 at 7:52 PM, Nathan Goings wrote: > I just setup NFS, and have gotten it working with my Windows 7 machine. > Basically, I'm working on a driver and want to use a graphical IDE. > > /etc/exports: > # > /usr -maproot=root -alldirs -network=192.168.37 -mask=255.255.255.0 > /usr/src -maproot=root -alldirs -network=192.168.37 -mask=255.255.255.0 > /mnt/drive2 -maproot=root -alldirs -network=192.168.37 -mask=255.255.255.0 > > (On windows) If I mount /usr, /usr/src is empty. I thought this was a > permission problem (thus, -maproot=root), then I thought it was a partition > problem (/dev/wd1f is mounted to /usr and /dev/wd1i is mounted to /usr/src). > > If I mount /usr/src alone, it works fine. Then if I mount /usr it continues > to work. However, if I mount /usr then /usr/src, it displays empty. > > Can anyone explain this? More importantly, is there a better way to achieve > this?
Re: /var/cache/fontconfig ??
On Sun, Jun 9, 2013 at 7:12 AM, Vadim Zhukov wrote: > 2013/6/9 Otto Moerbeek > >> On Sun, Jun 09, 2013 at 10:10:06AM +0100, Jason McIntyre wrote: >> >> > On Sun, Jun 09, 2013 at 05:06:01AM -0400, Jiri B wrote: >> > > >Sorry but this seems to bizzare to make 'cache' appropriate >> > > >subdir in /var just because of one specific tool. Wouldn't be >> > > >better to customize it to use /var/db/fontconfig? >> > > >> > > Ahh, on other machine there's also 'cups' and 'libvirt' :) >> > > >> > > jirib >> > >> > in that case my diff is definitely wrong. so i need a general >> > description of what /var/cache is for. >> > >> > jmc >> >> A cache holds stuff the is relativey expensive to recompute. If the >> data is thrown away, it can be regenerated. >> > > Is there any real difference with subdir under /var/tmp then? /etc/daily seems to prune files from /var/tmp based on whether they've been accessed in the last 7 days i would first trigger manual prunes to /var/cache and see how programs react > > -- > WBR, > Vadim Zhukov
Re: Linux localhost exploits
Owning since 2010! 2013/5/15 Martijn van Duren > Hello misc@, > > Just for laughs for those who don't work with Linux in their daily lives > and to present some gray hairs to those who do: > http://packetstormsecurity.com/files/121616/semtex.c > (applying patched kernels at my work as we speak) > > Sincerely, > > Martijn van Duren > > -- Atentamente Andrés Genovez Tobar / DTIT Tel: 842388 ext 177 Perfil profesional http://lnkd.in/gcdhJE
Re: who is using obsd
2013/5/14 Tomas Bodzar > On Mon, May 13, 2013 at 11:12 PM, Pau wrote: > > > on his/her laptop as *only* OS and uses it daily for scientific work? > > please contact me off list. Thanks > > > > > I'm not sure if there will be some official readings available (you can try > BSDmag and similar resources), but it's completely possible and fine as > long as there's SW you need in packages/ports or compilation works on your > own. And you know, here are in use tradional Unix/Unix-like things so > everything is possible. > > Yes, having it as desktop instead of Windows and/or Linux is working > perfectly. > > I don´t have much the Unix Guru Enterprise level, but I managed to work with Perl/Tk, and make nice programs, with Mysql, here are the source code of a program called Facturacion, http://www.crice.org/?q=node/84 tested on OpenBSD 4.3 Greetings -- Atentamente Andrés Genovez Tobar / DTIT Tel: 842388 ext 177 Perfil profesional http://lnkd.in/gcdhJE
Re: faxing
2013/4/22 Corey > On 04/22/13 12:30, Peter Fraser wrote: > >> Several years ago I put an OpenBSD system in as a firewall and mail >> server at a small charity that I volunteer at (kwaccessablility.ca) >> that fixed nearly all the problems that they had with viruses, spam etc. >> >> Last year I talked them in to switching to VOIP (on the OpenBSD server >> using Asterisk). Their phone costs dropped from over $250 >> per month to less than $30 per month (I used the service from >> unlimitel.ca). The change is costs per month made up for the costs >> of the new telephone equipment within the year. >> >> Nearly all their communication that was done by fax is now done by email, >> except for one organization. That organization which is >> run by the city supplies transportation for physically handicapped. That >> organization is insisting on faxes. They will not take email. >> The charity currently has an analog fax just for the purpose of arranging >> transportation, and that line is costing over $60 per month. >> >> I looked at email to fax services, but I believe those queue the faxes up >> and send them as time is available. The charity and >> the transportation organization need immediate sending and receiving. >> They carry out a conversation with hand written >> notes (requiring the charity to type the responses would not be a >> problem). >> >> Asterisk has a fax service, so I thought I could use that. But the >> Asterisk fax sending service requires TIFF in a directory >> and receiving service puts a TIFF file in a directory. >> >> The charity operates in a Windows environment. To the problem is: how >> does a person (probably a volunteer) >> on a Windows machine put a TIFF file into a directory on an OpenBSD, >> and in addition send the information >> as to where send the fax and get back a status on success or failure of >> sending a fax. >> >> I don't think receiving the fax will be that much of a problem; it >> should be easy to take the fax out the directory >> and send it as an email to a group mailbox. >> >> What I don't have is a good to solution for is how the person sitting at >> the Windows machine is to send a fax. >> There are some commercial solutions for Linux, but I have no idea if >> they operate OpenBSD. >> The commercial solutions are generally of the format that an email gets >> sent and fax is extracted from the text of the message. >> >> I would like to know if anyone has done something similar or any good >> suggestions on what I should do to >> get faxing to work >> >> Have you tried connecting your analog fax machine to an ATA (analog > telephone adapter) and then to your Asterisk box? It may not be what you > are looking for, but my fax machine works fine over my VoIP (Voipo is the > provider). I'm not using Asterisk, but if it's all SIP I wouldn't think > that would matter. > > Corey > > I think this is a clean solution, putting an ATA Works fine even for POS Machines (Credit Cards) that require a land line. -- Atentamente Andrés Genovez Tobar / DTIT Tel: 842388 ext 177 Perfil profesional http://lnkd.in/gcdhJE
How many rounds to use for a pbkdf2 encrypted disk?
The example in vnconfig shows 20,000. I picked 30K. This is a 2.8G core2 duo machine, encrypting mail and other stuff. I haven't found sources on the net that have explained what low security is, up to total paranoia with regards # of rounds. Ideas? URLs for good places to read? Thanks! --STeve Andre'
Re: [patch] tic man page file path error
On Sat, Mar 23, 2013 at 6:00 PM, Creamy wrote: > On Sat, Mar 23, 2013 at 05:31:15PM -0430, Andres Perera wrote: >> $ ident src/lib/libcurses/tinfo/read_bsd_terminfo.c >> src/lib/libcurses/tinfo/read_bsd_terminfo.c: >> $OpenBSD: read_bsd_terminfo.c,v 1.18 2010/01/12 23:22:06 nicm Exp $ >> $ grep -B2 -nw _PATH_TERMINFO src/lib/libcurses/tinfo/read_bsd_terminfo.c >> 22-#include >> 23- >> 24:#define _PATH_TERMINFO "/usr/share/misc/terminfo" >> -- >> 60- >> 61-/* Finally we check the system terminfo file */ >> 62:*fname++ = _PATH_TERMINFO; > > $ ls /usr/share/misc/terminfo > ls: /usr/share/misc/terminfo: No such file or directory > $ ls /usr/share/terminfo > 1 2 3 4 5 6 7 8 9 A E L M N P Q X a b c d e f g h i j k l m n o p q r s t u v > w x z your tree is messed up or you're running something other than -current $ grep -rw terminfo src/distrib/sets/lists src/distrib/sets/lists/base/mi:./usr/share/misc/terminfo.db src/distrib/sets/lists/comp/mi:./usr/share/man/man3/terminfo.3 src/distrib/sets/lists/comp/.#mi.1.969:./usr/share/man/man3/terminfo.3 src/distrib/sets/lists/man/mi:./usr/share/man/man5/terminfo.5 taking this to misc@
Re: Client-side font rendering system - from FAQ
as of msttcorefonts-2.0p0 the package does not override /etc/fonts/conf.d/31-nonmst.conf that's the one glaring exception i can think of (there are also old bmp fonts that install outside default paths, but i've no idea if such packages exist) On Sat, Mar 16, 2013 at 3:40 AM, James Griffin wrote: > I've added some fonts using pkg_add(1). Having looked at and read > http://www.openbsd.org/faq/truetype.html, in the section Client Side > Font Rendering, it says that fints added as a package from the "ports" > collection are registered automatically. Does this include when fonts > are added using pkg_add(1) or only when compiled from the ports tree? > > Because i've added fonts using pkg_add(1), i'm unsure if I need to > register them or not. Could someone confirm this? > > Thanks for your time, Jamie > > > -- > James Griffin: jmz at kontrol.kode5.net > > [A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38]
Re: WebRTC, google and firefox
well i believe vimscript is not aligned with my pillars either. vimscript is no where near aligned with anybody pillars i look at the usr/share dir for vim and i shudder. all of that file recognition and syntax highlighting is implemented in the worst language ever. and it's all bloated because color highlighting is for weird people anyway On Fri, Mar 8, 2013 at 1:22 PM, Dmitrij D. Czarkoff wrote: > On Wed, Mar 06, 2013 at 12:00:57PM -0430, Andres Perera wrote: >> dbus isn't big at all though, and it's even smaller when you consider >> that something else in your modern desktop env is going to end up >> depending on it >> >> i'm curious about what gnome components you are talking about. dconf, >> again, is miniscule > > Why do you assume that my desktop env is modern in sense of being D-Bus > enabled? Neither of its pillars - cwm, xterm, tmux and vim - has anything to > do with D-Bus. > > My point is not about the _size_ of dependencies, but rather about their > _nature_. See, I don't use any features of D-Bus, as none of the apps I > installed uses it. (Well, my browser does something on D-Bus, but (1) > optionally and (2) there is nothing else connected.) I am not even aware of > any useful way to use D-Bus. Obviosly, I don't need it. > > Same goes for dconf, as I keep all the settings I can out of dconf's touch, > just because I don't like it. To my knowledge, no dconf key is altered in my > setup, so I probably don't make any actual use of it anyway. > > -- > Dmitrij D. Czarkoff
Re: Intel hyperthreading w/ Atom E6xx & OpenBSD 5.2?
wait wait ~ can someone comment on this http://www.daemonology.net/hyperthreading-considered-harmful/ ? is it still in vogue? On Fri, Mar 8, 2013 at 12:31 AM, David Ruggiero wrote: >>> "The OpenBSD kernel and network stack still do run only on CPU0, so if > all you plan to do is >>> use PF to filter traffic, then you are indeed better off disabling HTT." > > > Thanks. That's the piece of info I needed, as (at least per current plans) > 95% of the machine's time will be in PF-land, with few or no userland > programs besides the occasional log-muncher. > > I do understand the ruleset for PF has changed, and then changed again, in > the intervening years. I planned to start from scratch with my rules, not > try to port anything from the old system except as a "don't forget to allow > this" kind of reminder. > > thx D > > > > On Thu, Mar 7, 2013 at 8:51 PM, System Administrator wrote: > >> On 7 Mar 2013 at 20:24, David Ruggiero wrote: >> >> > I've been using OpenBsd for 8+ years on my main router/firewall (4 >> > NICs). >> > Time to upgrade (I'm back on v3.8, yikes). Past time, really. >> > Solots to >> > learn / re-learn here. Have patience. First question: >> > >> > I'll be loading 5.2 on a low-power, Atom E640-based box (the Soekris >> > net6501). That chip has two Hyperthreading cores. Several >> > net-references >> > (esp. ca**mel.org ) advocate turning off HTT in the bios when using >> > OpenBSD >> > for faster interrupt servicing / task switching latency. >> > >> > Butperhaps that advice is pre-5.2, when we got pthreads(3) >> > support? >> > What's the best current advice for that kind of one-cpu, >> > multi-logical-thread system? >> > >> > 1) Single processor kernel or multi-processor (smp) kernel? >> > 2) If the latter, HTT turned on or off? >> > >> > Thanks. >> > Bonnie >> > >> > >> >> First thing first, read, read, and re-read the official documentation. >> Many things changed in the intervening years, in particular, PF >> configuration syntax has changed a fair bit. >> >> Do note that unlike the Linux world where you have to dig for third >> party "how-to"s, OpenBSD official documentation is very complete and up >> to date. Which is one of the reasons the website you referenced is >> frowned upon as most of its "information" is either out of date or >> simply wrong. That said, the particular point you bring up may still be >> valid -- much depends on your specific situation. >> >> Whether or not to use hyperthreading and multiprocessor (MP) kernel >> depends on the workload of your firewall. The OpenBSD kernel and >> network stack still do run only on CPU0, so if all you plan to do is >> use PF to filter traffic, then you are indeed better off disabling HTT. >> However, if your firewall is also going to be running a fair amount of >> userland processes (e.g. your website with db backend) then you may >> well benefit from multiprocessor support.
Re: A slight twist on the OpenBSD laptop question
it's not relevant because these aren't stand alone gpus... here in venezuela they're still selling clarkdales... i know because i just bought two. can someone else in a developing country offer their observations? i don't see the need to upgrade to sandy bridge ++ because my system can handle 1080p... even if it could handle more, broadband is 128K/12K really this whole obsd sucks for video thing is out of proportion On Wed, Mar 6, 2013 at 11:25 PM, Brad Smith wrote: > On Wed, Mar 06, 2013 at 12:10:18PM -0430, Andres Perera wrote: >> i don't think it's as drastic as that >> >> if you buy a Clarkdale cpu you're good to go >> >> these came out ~2010, they are still modern > > The issue isn't the CPU but the GPU and the GPUs in question come with > Sandy Bridge/Ivy Bridge based systems and anything newer. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean.
Re: A slight twist on the OpenBSD laptop question
i don't think it's as drastic as that if you buy a Clarkdale cpu you're good to go these came out ~2010, they are still modern On Wed, Mar 6, 2013 at 2:34 AM, Brad Smith wrote: > On Tue, Mar 05, 2013 at 11:00:01PM -0800, patrick keshishian wrote: >> On Tue, Mar 5, 2013 at 10:53 PM, Brad Smith wrote: >> > On Wed, Mar 06, 2013 at 07:36:58AM +0100, Matthieu Herrb wrote: >> >> On Mon, Mar 04, 2013 at 03:30:54PM +, Kevin Chadwick wrote: >> >> > I was about to buy two thinkpads which are often suggested when the >> >> > OpenBSD laptop question is raised but the 93 in stock have disappeared >> >> > since saturday, aaargh. >> >> > >> >> > There are still core2duos and lesser spec'd systems available which >> >> > has prompted me to ask the question I had pondered on. >> >> > >> >> > Does anyone know what the latest full screen (! widescreen) AMD laptops >> >> > would be that have excellent compatibility with OpenBSD or if 2Ghz is >> >> > the highest spec non core 2 duo and non widescreen reliable laptop >> >> > suitable for OpenBSD available? >> >> > >> >> >> >> If no idea which kind of graphics card the machine that you're >> >> considering has. This is probably the key point. Stay away from nVidia >> >> mobile chipsets and from recent AMD integated graphics. >> > >> > and recent Intel graphics. >> >> so what's left to chose from? :) > > That's the whole point. You're screwed running anything modern (so far). > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean.
Re: WebRTC, google and firefox
On Wed, Mar 6, 2013 at 8:40 AM, Dmitrij D. Czarkoff wrote: > One may notice that even minimalist web browsers (dwb, surf, uzbl, xombrero) > end up depending on D-BUS and GNOME components. Hell, even Qt-based Arora > pulls dconf. dbus isn't big at all though, and it's even smaller when you consider that something else in your modern desktop env is going to end up depending on it i'm curious about what gnome components you are talking about. dconf, again, is miniscule
Re: Precisions on ZFS (was: Millions of files in /var/www & inode / out of space issue.)
On Thu, Feb 21, 2013 at 9:59 PM, Juan Francisco Cantero Hurtado wrote: > OpenBSD doesn't have support for loadable kernel modules or FUSE, so > OpenBSD should include the code inside of the kernel. This is a big > difference with FreeBSD/NetBSD/Linux. lkm(4) is outdated with wrong information about a feature no longer present?
Re: Millions of files in /var/www & inode / out of space issue.
On Tue, Feb 19, 2013 at 8:11 AM, Nick Holland
wrote:
> I use ZFS, and have a few ZFS systems in production, and what it does is
> pretty amazing, but mostly in the sense of the gigabytes of RAM it
> consumes for basic operation (and unexplained file system wedging).
> I've usually seen it used as a way to avoid good system design. Yes,
> huge file systems can be useful, but usually in papering over basic
> design flaws.
funnily enough, that "avoid[ing] good system design" is exactly what
makes it useful for desktop over server. i don't want to spend any
time figuring out how much gigs for /usr/{src,xenocara}. i also don't
want to partition /usr/ports only to find out later on that there's an
"object" or "tmp" sub-directory that i want on a different fs but i
can't because i've hit the 16 partition limit
if i ever install an application for experimental reasons, because
it's not a production machine, i don't want to rethink everything to
fit inside the disklabel constraints either. "good system design"
doesn't apply because it's a case where, gasp, the admin couldn't
possibly plan ahead
Re: Legal Question: OpenBSD Spin-off
your comments hint to you not being very familiar with packages(7) you can distribute it as an executable that ultimately installs a package i say this because reusing the infrastructure, and having it take part of the db for easy removal and inspection is a great bonus. it means less work for you On Tue, Feb 12, 2013 at 10:08 PM, Crookedmaze wrote: > On 02/12/2013 04:26 AM, James Griffin wrote: >> >> - Jack Woehr [2013-02-11 15:46:29 -0700] - >> : >> >> >>> >>> If you need OpenBSD you have the technical skills to install it or you >>> know (and possibly pay) someone who does. >>> >>> OpenBSD, which is 20-ish years old now, was designed and is designed >>> and apparently always will be designed for those who have the >>> technical skills. >>> >>> If no, there is always Linux. >>> >> >> It is not designed for technically minded people; it is designed with >> security in mind and also a large amount of effort goes into making sure >> the code is well written. Yes many of its users are technically minded, >> but then there are technically minded people using FreeBSD and Linux, so >> i'm afraid your statement is rubbish - with all due respect. >> >> Learning how to use UNIX systems and shells and reading the >> documentation that's provided with the OpenBSD installation and on the >> OpenBSD website is all one needs to be able to grasp - that is not >> OpenBSD specific. >> >> It also provides an excellent development platform and a learning >> platform, >> which is why I use it. A person who might not have the skills to write >> kernel code for example doesn't mean they can't or shouldn't use >> OpenBSD. Provided one is willing to read and understand the information >> provided in man pages and other documentation - and ask the odd question >> here will have no trouble using and enjoying OpenBSD. I enjoy using very >> much and i'm not a skilled kernel programmer, for example. >> >> > > I agree this is actually why I choose to write my script specifically > for OpenBSD because of its excellent documentation and its also extremely > secure by default. Jan I don't think I am going to create a package for > my script because I plan on having people download my script via the > lynx browser then run it and it will not only configure the minecraft > server for them but also help them select a mirror to install packages > from etc. etc. (I am doing this to help out my target audience > which are most likely average users and new to the Command Line > Interface). > > -Crookedmaze
Re: bootable OpenBSD USB stick from windows?
On Tue, Feb 12, 2013 at 8:29 AM, Heptas Torres wrote: > On 2/12/13, Jan Stary wrote: >> On Feb 11 23:55:30, hepta...@gmail.com wrote: >>> On 2/11/13, Jiri B wrote: >>> > On Mon, Feb 11, 2013 at 10:51:29PM +, Heptas Torres wrote: >>> >> Hello >>> >> I have an old laptop with no CD-ROM but can boot from USB. Given that >>> >> I only have access to a windows machine to burn an iso image, do you >>> >> know of an easy way (e.g. some windows programa) to create a bootable >>> >> OpenBSD USB stick which I can then use to install OpenBSD on my old >>> >> laptop? >>> >> -heptas >>> > >>> > Install OpenBSD on your usb stick on this "Windows" machine, >>> >>> How to do that exactly from windows when I cannot boot OpenBSD on that >>> machine? >> >> why can't you? > > because I don't have an OpenBSD booting media (the laptop has no > CD-ROM, and I don't have bootable USB drive with OpenBSD - that's > where I'm trying to get to). > -heptas > install qemu (does it run on windows?) or virtualbox, boot the official iso on it, mount usbkey from the qemu obsd instance, install to that that gives you a bootable usbkey with openbsd on it without having to possess more than one system and without buying an optical drive there's been many threads like these in the past btw. whatever
Re: bug / misunderstanding in how pf interacts with dhclient
On Tue, Jan 29, 2013 at 4:28 AM, Bohdan Tashchuk wrote: > --- On Mon, 1/28/13, Andres Perera wrote: > >> more than that, really, why should you or anybody care >> >> using bpf or not should be an implementation detail. no one should >> be making decisions as far as their pf config goes based upon >> whether dhclient uses bpf or not > > Thanks for your comments on the source code. I briefly looked thru > /usr/src/sbin/dhclient, but there were 6289 lines of *.c code there. > I'm not that familiar with networking code so there was too much > for me to easily comprehend. in the future, you can use systrace to find out what fd programs are really writing to. it has saved me enormous amounts of time when troubleshooting, e.g., cvs slowness. familiarizing myself with cvs's code base would've undoubtedly been more expensive > > I agree that bpf is simply an implementation technique; I don't really care > *how* dhclient does what it does. But I want to understand the required pf > rules for two reasons: > > 1) there have been people who have said (e.g. in the thread I quoted): > >"Using DHCP is not possible, pf block it, and i don't understand why" > > Missing pf rules are one reason why dhcp would fail. Many people search > for similar problems years later; I don't want them to be confused as I was. > > 2) This is the important one for me. I want to be a "good Internet citizen". > So I try to write my pf rules to be as restrictive as possible. I want to > keep machines behind my firewall from being "bad Internet citizens". > Right now my outgoing UDP below port 1024 is restricted to ports domain, > kerberos, and ntp. I will add dhcp to that list. > > I know I'm being a little quixotic (or perhaps pedantic) here. If there's > a misbehaving machine behind my firewall, I don't think that restricting > its UDP ports is going to make a whole lot of difference to the Internet > at large. But I'm trying to do what I can. > as it stands, i would wait for an "official" recommendation before jumping to conclusions. i'm only pointing out the problem. it could be that routing these unicast messages is useful, which is why they aren't being written directly to the interface's output buffer via bpf, or it could very well be that someone is devising a patch to write them through bpf regardless because the routing isn't required... that's a problem area i'm not familiar with, but i would expect $router_network == $dhcpd_network in common configurations... and even if not, having them potentially route through different interfaces makes no friggen sense
Re: bug / misunderstanding in how pf interacts with dhclient
On Tue, Jan 29, 2013 at 12:52 AM, Andres Perera wrote: > On Mon, Jan 28, 2013 at 7:43 PM, Bohdan Tashchuk wrote: >> Hi guys, >> >> For many years, I've read pf and dhcp related threads like, e.g.: >> http://marc.info/?l=openbsd-misc&m=125907434809727&w=2 >> >> Some text from that post: >> "dhcp packets are grabbed by dhclient or dhcpd before pf sees them." >> >> My understanding, based on comments in a number of threads like that, >> is that NO MATTER WHAT IS IN PF RULES, that dhcpd and dhclient should >> both work fine. This is because dhcpd and dhclient both use bpf to >> completely bypass pf. > > when dhclient sends an unicast message, such as when renewing a lease, > it doesn't use bpf fd... it uses a "regular" socket and writes to it > using sendmsg() > > the relevant code is send_packet() in src/sbin/dhclient/bpf.c and > if_register_send() in the same file for the unicast socket > instantiation routine more than that, really, why should you or anybody care using bpf or not should be an implementation detail. no one should be making decisions as far as their pf config goes based upon whether dhclient uses bpf or not ideally dhclient should be able to write broadcast messages without bpf! it wouldn't be a significant simplification but it's still something
Re: bug / misunderstanding in how pf interacts with dhclient
On Mon, Jan 28, 2013 at 7:43 PM, Bohdan Tashchuk wrote: > Hi guys, > > For many years, I've read pf and dhcp related threads like, e.g.: > http://marc.info/?l=openbsd-misc&m=125907434809727&w=2 > > Some text from that post: > "dhcp packets are grabbed by dhclient or dhcpd before pf sees them." > > My understanding, based on comments in a number of threads like that, > is that NO MATTER WHAT IS IN PF RULES, that dhcpd and dhclient should > both work fine. This is because dhcpd and dhclient both use bpf to > completely bypass pf. when dhclient sends an unicast message, such as when renewing a lease, it doesn't use bpf fd... it uses a "regular" socket and writes to it using sendmsg() the relevant code is send_packet() in src/sbin/dhclient/bpf.c and if_register_send() in the same file for the unicast socket instantiation routine
Re: pf rule idea
i highly doubt that they would add any sort of layer 7/string checking capability to pf. it's completely against its design that's just not going to happen
Re: getting apps en masse
there are ways, including pkg_add it seems that's not good enough, and i'm guessing it's because downloading->installing isn't parallelized... you can use other clients; ftp, http, rsync, afs (lol) to download packages On Thu, Jan 24, 2013 at 9:00 PM, John Newton wrote: > Sirs: Is there a way to download whole multipage chunks of the Apps from any > of the mirrors? I need to study them at my leisure offline and the one-by-one > method is tedious. Thanks from john
Re: OT using absolute paths in scripts
On Mon, Jan 14, 2013 at 1:49 PM, Claer wrote: > On Sun, Jan 13 2013 at 04:11, Maximo Pech wrote: >> At work, we have an "information security" area for IT. >> >> They mandate that on all shell scripts we have to use absolute paths for >> every single command. >> >> I feel that this does not provide real security and only makes scripts >> somewhat more painful to write. >> >> What's your opinion on this? > > I saw that technique used, but not for security reasons. Is it the only > recomendation they've done or there are others? > > Because if it is the only one, then you can break through this pretty easily: > $ export IFS='/ > ' POSIX 2.5.3, Shell Variables, IFS: Implementations may ignore the value of IFS in the environment, or the absence of IFS from the environment, at the time the shell is invoked, in which case the shell shall set IFS towhen it is invoked. "may" isn't a requirement, but what's a standard if a significant amount of implementations agree on what's right? andres@pote:~/tmp $ IFS=asd bash -c 'echo "$IFS"' | vis \t\$ \$ andres@pote:~/tmp $ IFS=asd ksh -c 'echo "$IFS"' | vis \t\$ \$ therefore i conclude that you are talking out of your poopy hole
Re: Running OpenBSD on Raspberry Pi
2013/1/9 Gene > On Wed, Jan 9, 2013 at 10:54 AM, Andres Genovez > wrote: > > 2012/12/31 BARDOU Pierre > > > >> Hello, > >> > >> I would be very interested by an OpenBSD port too. > >> Usage : home router with firewall, DNS and DHCP. > >> > >> I am looking into FreeBSD and NetBSD ports, but I would prefer to have > the > >> latest PF and OpenSSH versions... plus I am more used to OpenBSD and I > like > >> using it :-) > >> > >> If somebody knows X86 hardware able to do the same (routing/firewlling > 20 > >> mbps traffic, VLAN, fits in a tiny box, power consumption below 5W, > price > >> around 50$) as the raspberry I am interested BTW. > >> > > I am interested too, can somebody give an advice on what hardware to use? > > maybe 5 lan or at least two lan? an below 100? > > > > For under $100 USD your best bet is to look for a used computer on > craigslist or a yard sale and install another NIC in it. But, this > will not get you at 5 watts or less. > > For under $200 look at either PC Engines ALIX boards or Soekris. eBay > has plenty of them. You can manage 5W or less this route. > > For the Raspberry Pi you will not get OpenBSD. You will have to use > Linux and configure it manually, including recompiling the kernel with > iptables support. You *might* be able to get under $100, but it won't > be under 5 watts and it will be a jalopy. USB ethernet adapters start > around $25 new. > > Thanks, i will look forward those, because a Mikrotik is under 100, and features over 1000. > -Gene > -- Atentamente Andrés Genovez Tobar / DTIT Elastix ECE - Linux LPI-1 - Novell CLA - Apple ACMT - Mikrotik MTCNA/MTCTCE/MTCRE/MTCWE http://www.cspmsa.com
Re: Running OpenBSD on Raspberry Pi
2012/12/31 BARDOU Pierre > Hello, > > I would be very interested by an OpenBSD port too. > Usage : home router with firewall, DNS and DHCP. > > I am looking into FreeBSD and NetBSD ports, but I would prefer to have the > latest PF and OpenSSH versions... plus I am more used to OpenBSD and I like > using it :-) > > If somebody knows X86 hardware able to do the same (routing/firewlling 20 > mbps traffic, VLAN, fits in a tiny box, power consumption below 5W, price > around 50$) as the raspberry I am interested BTW. > I am interested too, can somebody give an advice on what hardware to use? maybe 5 lan or at least two lan? an below 100? > > -- > Cordialement, > Pierre BARDOU > > > -Message d'origine- > De : Doug Brewer [mailto:brewer.d...@gmail.com] > Envoyé : lundi 31 décembre 2012 09:39 > À : KarlOskar Rikås; misc@openbsd.org > Objet : Re: Running OpenBSD on Raspberry Pi > > On Mon, Dec 31, 2012 at 12:13 AM, Tobias Ulmer wrote: > > On Sun, Dec 30, 2012 at 05:01:23PM +0100, KarlOskar Rikås wrote: > >> Hi, I wonder if it's possible to run OpenBSD on Raspberry Pi. > >> > >> Is there any image ready for putting on my SD card and boot up? If > >> not, is there any manual or guide how to make one? > > > > No it's not possible and there are no plans to change that. Search the > > archives if you're interested in the reasons. > > > > In short, there is plenty of better performing and better documented > > hardware available for nearly the same price. This makes the rpi > > unattractive for developers. > > If so, try install FreeBSD. Last time I checked, it worked pretty well for > me. > > BR, > Doug. > > -- Atentamente Andrés Genovez Tobar / DTIT Elastix ECE - Linux LPI-1 - Novell CLA - Apple ACMT - Mikrotik MTCNA/MTCTCE/MTCRE/MTCWE http://www.cspmsa.com
Re: Strange ksh history behaviour
I've been using a patch I made months ago. I haven't submitted it to tech@ since I believe people actually want to keep it. I can't post it at the moment because it's just on the CVS checkout and I have other ksh changes that I have to split first.
Re: Various system freeze
2012/12/29 epsilon > Hi all, > > recently we read a lot of total system freezes. Let me try to > summarize: > > Common in many cases is: The system totally freezes. No keyboard > interaction possible. No kernel panic. No coredump. Nothing in the > logs. Network (ICMP, routing) looks up. But no userland action. > > Different are the situations: Some users observe this during boot, > others in X during night, some see a high diskio just before the > freeze, others see heavy network load. Some systems run in a VM, > others on real hardware. Sometimes the issue is reproducable at the > same time during night, in other cases it occurs randomly. > > So we have a wide variety of situations, but often the same result: > Total freeze without any log or coredump. > > Let's assume all this cases have someting in common. Than something > very fundamental is broken. > > On the other hand, is it really likely all this cases are different > bugs? > > To all the users: Thanks for all the reports. > > To the developers: What is to provide if users did not have anything > in their logs, no cordeump, nothing. Only a total frozen system? Maybe > dmesg and config files, right? And a verbal description what happens, > right? > > - Eps > > Maybe faulty hardware? memory banks? -- Atentamente Andrés Genovez Tobar / DTIT Elastix ECE - Linux LPI-1 - Novell CLA - Apple ACMT - Mikrotik MTCNA/MTCTCE/MTCRE/MTCWE http://www.cspmsa.com
Re: A point about the BSD license I'm feeling edgy about
On Fri, Dec 28, 2012 at 9:03 PM, Live user wrote: > On 29/12/2012 2:28, Andres Perera wrote: >> >> Consider GNU autoconf. the output isn't derivative work of the source >> files, regardless of how big their BSD headers are. >> >> That's the biggest problem with autoconf, imo; not the idiosyncrasies >> of the language. > > > Since when documentation is a derivative work of something that is not > documentation? Obviously, I consider a derivative work, to something that if > you do reverse engineering or decompile ont, you can get more or less to the > original code, which is not the case. > I'm not sure how documentation ties in. Other then that, I don't see an active movement challenging autoconf maintainers on the FSF copyright that invariably appears in the output. What is the copyright referring to? Is it outlandish to interpret it as a claim on the file? I sure as hell did.
Re: A point about the BSD license I'm feeling edgy about
On Fri, Dec 28, 2012 at 8:50 PM, Live user wrote: > > 3) The copyright holder of the object files is the original author even if > the compiler is a third party person > Nope, that depends on the compiler/transformation. Consider GNU autoconf. the output isn't derivative work of the source files, regardless of how big their BSD headers are. That's the biggest problem with autoconf, imo; not the idiosyncrasies of the language.
Re: High performance IO (sendfile(), caching, and libev(ent))
On Thu, Dec 20, 2012 at 6:06 AM, Tobias Ulmer wrote: > > The file will be in the buffer cache. While it still takes a few > in-memory copies (which is what sendfile saves you), this should be fast > enough for most cases. > > If you keep the data in your address space, you save one m-to-m copy, > but ignore all the benefits that the bc has compared to you (namely > knowing how much free memory really is available at runtime, not forcing > buffers into swap and more). this is called optimizing for the worst case of resource starvation over disk usage. clearly a question of priorities 1. the kernel file buffer cache having knowledge about free mem alone is irrelevant because sendfile() has the capability of returning ENOMEM 2. if you are hitting swap, buy more memory or stop sending so many/as big files > You will probably end up shooting yourself > in the leg for a speed gain that probably can't be realized because the > network is the real bottleneck > > Taking memory away from the kernel to duplicate functionality in > user-space is almost never a good idea. > >> >> Normally I would just write both and profile them, but I can't figure >> out how to do the first on OpenBSD.
Re: High performance IO (sendfile(), caching, and libev(ent))
On Thu, Dec 20, 2012 at 4:23 AM, Jean-Philippe Ouellet wrote: > Hello, > > I'm trying to learn about writing high performance servers, and I have a > few questions not clearly answered by any documentation I can find. I'm > comfortable with select(), poll(), and kqueue(), but that only goes so > far. I'm currently looking into how to send static files (over a > network) with the least amount of overhead. > rest assured this is not the right avenue a few moons ago there was a discussion involving a converse client issue certain people did not understand why firefox opens so many sockets since select() and cousins are used in situations where concurrent socket io is desirable (if only because of inadequacies of http), you want to go to a place where they write high throughput servers. you won't find that in openbsd outside of non-tcp servers and contribs like nginx
Re: trivial with echo command
On Tue, Dec 18, 2012 at 6:32 AM, Marc Espie wrote: > On Tue, Dec 18, 2012 at 11:47:59AM +0100, Alexander Hall wrote: >> >> >> Andres Perera wrote: >> >> >On Mon, Dec 17, 2012 at 7:07 PM, Alexander Hall >> >wrote: >> >> >> >> For scripting, echo is one of the commands I tend to avoid unless I >> >know the >> >> data is "safe", because of it's horrific argument parsing. >> >> >> >> I've yet to find a way to echo a single '-n' using the sh/ksh >> >builtin. When >> >> printing unknown data, I usually end up using 'print -r -- "$var"' >> >(or >> >> 'printf "%s" "$var"' if I care about portability). >> >> >> >> /Alexander >> >> >> > >> >the worrysome part is what happens with make: >> > >> >andres@pote:~ $ echo '/nonexsistent:;@echo -e hello' | make -f- | vis >> >-e hello\$ >> >andres@pote:~ $ echo '/nonexsistent:;@echo -e hello;' | make -f- | vis >> >hello\$ >> > >> >this is due to the optimization to fork+exec instead of shell when >> >there are no meta characters. the second makefile has `;', so the >> >optimization doesn't get triggered >> > >> >what is the problem? 2 echos that disagree or the optimization itself? >> >are the calls coming from *INSIDE* the house? >> >> I don't think make should optimize this, but recognize echo as a shell >> builtin. > Is this theoretical, or is there an actual Makefile where this is a problem ? > > I'd rather NOT go through extra shell forking just for the sake of it. > > Also, echo -e is specific to ksh and NOT a posix option, so you're going > to end up with something that is deeply non-portable. > > Either way, this is fucked up. > i believe it is theoretical because i can't find a way to embed a backslash without skipping the optimization. using `-e' without backslashes would be pointless i still think both echos should agree out of principle, even though them agreeing isn't immediately useful the make optimization is perfectly valid, and other makes do something similar
Re: trivial with echo command
On Mon, Dec 17, 2012 at 7:07 PM, Alexander Hall wrote: > > For scripting, echo is one of the commands I tend to avoid unless I know the > data is "safe", because of it's horrific argument parsing. > > I've yet to find a way to echo a single '-n' using the sh/ksh builtin. When > printing unknown data, I usually end up using 'print -r -- "$var"' (or > 'printf "%s" "$var"' if I care about portability). > > /Alexander > the worrysome part is what happens with make: andres@pote:~ $ echo '/nonexsistent:;@echo -e hello' | make -f- | vis -e hello\$ andres@pote:~ $ echo '/nonexsistent:;@echo -e hello;' | make -f- | vis hello\$ this is due to the optimization to fork+exec instead of shell when there are no meta characters. the second makefile has `;', so the optimization doesn't get triggered what is the problem? 2 echos that disagree or the optimization itself? are the calls coming from *INSIDE* the house?
Re: trivial with echo command
On Mon, Dec 17, 2012 at 6:13 PM, Stuart Henderson wrote: > On 2012-12-17, sven falempin wrote: >> Hello misc readers, >> >> First, openBSD threads are awesome for debugging. >> The trivial topic, >> echo -ne "\x00" | nc port >> send a null byte with a GNU echo. >> >> Echo in openbsd does not have -e (and does not warn whan i try it ..) >> >> Noob question: >> How to send a null byte over netcat ? am i forced to use perl ? > > you can use octal with echo(1) or printf(1). echo(1) is BSD echo (no backslash sequences) ksh echo is XSI + BSD > > $ echo -n '\000' | hexdump -C > 00|.| > 0001 > > $ printf '\000' | hexdump -C > 00|.| > 0001
Re: trivial with echo command
echo expands nil from C backslash sequences just fine: andres@pote:~/tmp $ alias vis vis='vis -cl -F$COLUMNS' andres@pote:~/tmp $ echo '\0a' | vis \0a\$ andres@pote:~/tmp $ perl -e 'print "\0a\n"' | vis \0a\$ what's most likely happening is that the protocol that you're targeting treats '\0' as some kind of delimiter: andres@pote:~/tmp $ echo '\0a' | nc localhost 587 220 pote.my.domain ESMTP Sendmail 8.14.5/8.14.5; Mon, 17 Dec 2012 16:13:51 -0430 (VET) 500 5.5.1 Command unrecognized: ""
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 8:07 AM, Alexander Hall wrote: > > I still want to know the reason for all this. If it's for security, it sure > feels ass-backwards and questionable at best. > it's useful for honeypot scenarios, with all proposed solutions so far being influenced by either lazyness or desire to maintain a modicum of portability with other unices. it's not useful for accounting on regular accounts the best balance between effort and results i believe is to extend the ktrace hooks to switch on curproc uid and put a cap on the logfile. what apis linux honeypot loggers use? do they sufficiently resemble ktrace? it's the only facility i see in openbsd besides systrace that fits the bill of already logging all sorts of io (not just pty)
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 7:10 AM, Paul de Weerd wrote:
> On Sun, Dec 16, 2012 at 06:38:08AM -0430, Andres Perera wrote:
> | On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd wrote:
> | > On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
> | > | > .profile can be interrupted with ctrl+c.
> | > |
> | > | >>> Because it is under controle or the user and he/she can disable
> | > | >>> such funcionality.
> | > |
> | > | the safer way imho is patching ksh
> | >
> | > After that, expect all your users to suddenly switch to one of the
> | > other shells available on your system...
> |
> | because once you patch ksh, you can't ever again edit /etc/shells
>
> switching shells:
>
> Step 1: login
> Step 2: exec (zsh|csh|perl|tcsh|bash|...)
> Step 3: ...
> Step 4: profit
>
> Sure, you can edit /etc/shells and prevent users from changing their
> login shells with chsh, but what does that buy you if they can still
> switch shells ?
no, you are patching ksh for a reason. you add logging capabilities
and remove the ability to exec. is it a featureful shell, not really
then again, is the resulting patched ksh significantly different than
some free shell hosts provide? nope, they both tend to be as useless.
if i recall correctly, sdf had such a stunted shell
>
> And besides .. the users that want to run another shell in the first
> place are screwed ? You'd have to patch 'em all .. good luck with
> maintaining that.
the alternative login shell below is even more restrictive; only
/bin/sh. ksh in posix mode isn't fun at all. this is the price you pay
for security in 2013
>
>
> Then, you could log all stdin/stdout to some file (even more data!
> fun!). If you really want to circumvent this logging, you could
> create a covert channel that will show data on the client side but has
> no visible input/output in the server side.
well, it's logging terminal input. does what it says in the can
the can doesn't say "logs arbitrary socket io"
>
>
> I'm still curious why any of this is a good idea.
>
> | > Or a nice syslog DoS, where people run while :; do echo ${RANDOM} >
> | > /dev/null; done (or a less intentional version of the same) to flood
> | > your logs with crap.
> |
> | and fsize becomes immutable as well apparently (syslog be forgotten)
>
> Not sure I understand your point here. What about fsize ? You want
> to limit the size of the logfile ? So that all you have to do is fill
> it up to the max size and then you can do whatever you want without
> having your actions logged ?
now that i think about it, it wouldn't work with O_APPEND ~O_CREAT on
the logfile below
i'm not sure "whatever you want without having your actions logged" is
accurate in the original case, since ksh aborts by default on SIGXFSZ
and modifications to builtins can make it uncatchable
in any case, presumably the quota system is up to spec and the writing
is done entirely by the user
Re: KSH command logged to syslog
btw, this program should be the only entry in /etc/shells so only root
is allowed privacy
On Sun, Dec 16, 2012 at 6:38 AM, Andres Perera wrote:
>
> #include
> #include
> #include
> #define sp "/usr/bin/script"
> #define sf "/var/db/ghetto_act/%ju"
>
> main()
> {
> char *so;
> if (asprintf(&so, sf, getuid()) == -1) return 1/0;
> execl(sp, sp, "-a", so, NULL);
> return 1/0;
> }
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd wrote:
> On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
> | > .profile can be interrupted with ctrl+c.
> |
> | >>> Because it is under controle or the user and he/she can disable
> | >>> such funcionality.
> |
> | the safer way imho is patching ksh
>
> After that, expect all your users to suddenly switch to one of the
> other shells available on your system...
because once you patch ksh, you can't ever again edit /etc/shells
>
> Or a nice syslog DoS, where people run while :; do echo ${RANDOM} >
> /dev/null; done (or a less intentional version of the same) to flood
> your logs with crap.
and fsize becomes immutable as well apparently (syslog be forgotten)
here is something that doesn't require patching
create log files and change to system append-only with chflags. dir
should be, e.g., chown root:wheel, chmod go=rx
#include
#include
#include
#define sp "/usr/bin/script"
#define sf "/var/db/ghetto_act/%ju"
main()
{
char *so;
if (asprintf(&so, sf, getuid()) == -1) return 1/0;
execl(sp, sp, "-a", so, NULL);
return 1/0;
}
>
> Why is this a good idea, exactly ?
>
> Paul 'WEiRD' de Weerd
>
> --
>>[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
o look, a brainfuck program. this is so quirky and tech oriented i
feel identified with you
> http://www.weirdnet.nl/
Re: SSHD doesn't honor login.conf's setenv
as a temporary workaround, you can do sudo -u $SAMEUSER -c - -i in, e.g., ~/.profile at the logged-in machine that way you don't duplicate env settings in ssh_config proper On Tue, Dec 11, 2012 at 6:14 AM, Martijn van Duren wrote: > Dear misc, > > I'm a new to OpenBSD and BSD in general. > > On my new install I found that it is possible to set environment > variables via the login.conf file. When trying I found out that those > variables aren't honored if I log in via ssh. Setting the variables via > setusercontext in a test-application and via the login command does > work. > > Am I somehow missing a setting in sshd_config that ignores these > settings or do I need to report this as a bug? > > Sincerely, > > Martijn van Duren
Re: upstream vendors and why they can be really harmful
(cc'ing misc instead of tech) On Sat, Nov 24, 2012 at 7:21 PM, William Ahern wrote: > On Thu, Nov 22, 2012 at 01:27:46PM -0430, Andres Perera wrote: >> On Thu, Nov 22, 2012 at 11:58 AM, Kevin Chadwick >> wrote: >> > On Thu, 22 Nov 2012 09:30:41 -0430 >> > Andres Perera wrote: >> > >> >> i'm not sure how using js for configuration files, as opposed to using >> >> a language commonly deployed for the same purpose, such as lua, >> >> presents an innate constraint on security. >> > >> > Firstly the article mentioned JIT preventing true randomisation. >> > >> > Secondly pulling in JS as a dependency even on servers is rediculous and >> > is a language very familiar to attackers and unfamiliar to many users. >> > It would be especially, shall we say kind to attackers utilising rop >> > attacks. >> >> but jit isn't irreparably interleaved with js >> >> am i compromising by running luajit in interpreter mode instead of the >> reference implementation > > Almost certainly, yes. And that's not a slight against Mike Pall's skills. > Complexity is the enemy of security, every time. Merely disabling a feature > doesn't remove its footprint from the code base. lets make something clear: using luajit as an example does not impose a strict meaning on "disable". consider it an absolute requirement that "disables" entails: not using mmap or mprotect directly, and more importantly, impose memory layout constrictions outside of what system malloc would > > And have you read any of those codebases? The reference Lua implementation > is a model of clear programming, IMO. > >>, moreover, would that imply that lua the language is insecure or is the >> specific implementation at fault? > > Lua-the-language is designed with implementation details in mind. When an > implementation details become intolerably complex, they consider removing > the feature (e.g. the new generational collector in 5.2). i'm not interested in defending the position that having the ability of choosing between two allocators, or even that the allocator is exposed to the user at all, is part of the language. i consider it a stupid argument to participate in. if the intention was to evoke the idea that, in the real world, implementation and design are not conveniently independent, then i would ask for an example that correspondingly uses an implementation detail that is relevant to the light use expected out of a configuration language by a project like polkit >> >> why would the runtime be attractive for rop? what configuration vm >> needs syscalls that would be attractive to an attacker that can change >> the address of a jump? does the runtime really need to open sockets, >> or spawn processes? (i'm not even talking about languages) > > Those syscalls are accessible in the run time environment, whether or not > they're intentionally bound. And that's all that matters, at the end of the > day. If intentions drove run time safety, there would never be attacks > against real-world code. i'm also not interested in perpetually repeating myself, specially when opposing opinions differ on what's lacking in the imaginary, js-driven sudo program. in the same message you quoted i used systrace (no deferred arg-check) as a deterrent. there's no need for overly simplistic quips like "If intentions drove run time safety, there would never be attacks against real-world code"; i don't see how those promote discussion at all
Re: Crowding out OpenBSD
On Sat, Nov 17, 2012 at 3:20 AM, Eric Furman wrote: > You missed the point. > This is a joke. > Rod was making a joke by pointing out how F** retarded these people > are. i'm going to pretend that you pointed out that cgroups prevent double-forking from being a factor whereas pgroups do not this is a question of policy, not api: 1. if a program double-forks, that program has made it clear that it does not need the destructors scripted in "systemd implementation", and is eligible for being terminated by the generic, all-encompasing, sysv killall(), linux killall5, or bsd kill(-1) at the end of shutdown. this conclusion is drawn by the fact that the program can negate scripted destructors ANYWAY under cgroups by way of being unrestricted in its set of system calls (which is a concern OUTSIDE "systemd implementation", therefore the role of a more generic utility), or by plain bat shit insane userland code. there's no sandbox being added by cgroups here 2. if a program double-forks, security is not compromised because the permissions of that program are completely orthogonal to control via "systemd implementation". the admin's *policy* is that there's always an interest in running certain daemons as certain users. that "systemd implementation" can also map processes to users is coincidental therefore the requirement for cgroups is completely arbitrary also of interest: * early versions of systemd documentation advised daemon authors not to double fork. presumably cgroups wasn't in the radar at the time * several (all?) openbsd daemons have options for not double-forking. some of these daemons have the gall of preceding systemd > > On Sat, Nov 17, 2012, at 02:21 AM, Andres Perera wrote: >> On Sat, Nov 17, 2012 at 1:55 AM, Rod Whitworth >> wrote: >> > On Fri, 16 Nov 2012 20:49:37 -0600, Amit Kulkarni wrote: >> > >> >>https://lwn.net/Articles/524606/ >> >> >> >>don't have a subscription but for those who do, enjoy. >> >> >> > >> > But http://lwn.net/Articles/524920/ will give you the idea without $$$ >> >> "rleigh, it's really not as easy as you think. Making the event loop >> portable to kqueue is complex, but doable, I can agree to that. -- But >> the trouble starts beyond that. The BSDs don't have anything like >> cgroups. *There's no way to attach a name to a group of processes, in >> a hierarchal, secure way*. And you cannot emulate this. (And no, don't >> say "BSD jail" now, because that is something very different). But >> this already is at the very core of systemd. It's how systemd tracks >> services." >> >> how can someone write this and not explain why a process managing >> pgroups can't achieve the same results? >> >> pgroups is going to be the first alternative for someone instinctively >> looking for a portable alternative, so i'm genuinely interested in >> knowing why they've discarded the idea >> >> i am, however, aware of differences *unrelated* to writing a systemd >> like appliance. pgroups do not provide per item hostname and other >> virtualization facilities in freebsd jails/linux cgroups, but what >> about *relevant* differences? something weak like "the index for for >> cgroups is wide enough to fit an UUID"? in other words, something that >> *doesn't* require a completely new api?
Re: Crowding out OpenBSD
On Sat, Nov 17, 2012 at 1:55 AM, Rod Whitworth wrote: > On Fri, 16 Nov 2012 20:49:37 -0600, Amit Kulkarni wrote: > >>https://lwn.net/Articles/524606/ >> >>don't have a subscription but for those who do, enjoy. >> > > But http://lwn.net/Articles/524920/ will give you the idea without $$$ "rleigh, it's really not as easy as you think. Making the event loop portable to kqueue is complex, but doable, I can agree to that. -- But the trouble starts beyond that. The BSDs don't have anything like cgroups. *There's no way to attach a name to a group of processes, in a hierarchal, secure way*. And you cannot emulate this. (And no, don't say "BSD jail" now, because that is something very different). But this already is at the very core of systemd. It's how systemd tracks services." how can someone write this and not explain why a process managing pgroups can't achieve the same results? pgroups is going to be the first alternative for someone instinctively looking for a portable alternative, so i'm genuinely interested in knowing why they've discarded the idea i am, however, aware of differences *unrelated* to writing a systemd like appliance. pgroups do not provide per item hostname and other virtualization facilities in freebsd jails/linux cgroups, but what about *relevant* differences? something weak like "the index for for cgroups is wide enough to fit an UUID"? in other words, something that *doesn't* require a completely new api?
Re: Is this legal CVS?
On Tue, Oct 23, 2012 at 6:59 AM, John Long wrote: > > However, updates must be done directory-by-directory" > > Based on this I was doing it directory-by-directory but based on Tomaz's > post quoted above it seems you can combine directories for CVS up also? If > this is correct it would be nicer (and possibly more correct) than doing > three seperate CVS ups. Is the FAQ wrong and/or has CVS changed to allow > this, is it a good practice? > i had a related issue where one server limited argc in their anoncvs inetd handler. co or up, only one module was allowed, so i would suggest doing it per module regardless of whether you're doing a checkout or not
Re: nasm problem - SOLVED
On Mon, Oct 15, 2012 at 10:41 AM, John Long wrote: > On Mon, Oct 15, 2012 at 09:48:57AM -0500, Chris Bennett wrote: >> On Mon, Oct 15, 2012 at 09:31:34AM -0500, Chris Bennett wrote: >> > I have added this: >> > >> > section .note.openbsd.ident >> > align 2 >> > dd 8 >> > dd 4 >> > dd 1 >> > db 'OpenBSD',0 >> > dd 0 >> > align 2 >> > >> > But get error: >> > >> > sfhello.asm:1: error: segment name `.note.openbsd.ident' not recognized >> > >> >> This does work fine if I do this: >> add note section then compile like this: >> >> nasm -f elf32 -o sfhello.o sfhello.asm >> ld -m elf_i386_obsd -o sfhello sfhello.o >> ./sfhello >> Hello, world! >> >> Anything wrong with this method? > > No, but it is often easier to let gcc invoke the linker. > > instead of > > ld -m elf_i386_obsd -o sfhello sfhello.o > > you could do > > gcc -o sfhello sfhello.o > that fails to link because _start would be defined in crt, and passing -nostdlib isn't enough because some pie thing needs atexit. the final command line with -nopie ends up being more complicated than calling ld
Re: tmux and current directory
more of a case of man gratuitously changing cwd
shells spawned by $PAGER also have a cwd of the base of the man path
On Sun, Sep 30, 2012 at 12:38 PM, Jan Stary wrote:
> On current/i386, tmux seems to open a new shell with the current
> directory being the same as in the window I am opening from.
>
> What that means in particular is that if I run 'man whatever'
> in a tmux window, and open a new windowd ('ctrl-b c' in my case),
> the news shell is opened in /usr/local/man. Is that inteded?
>
> Jan
Re: !!!!
On Wed, Sep 5, 2012 at 6:34 PM, Kevin Chadwick wrote: > On Wed, 5 Sep 2012 16:49:34 -0430 > Andres Perera wrote: > >> On Wed, Sep 5, 2012 at 4:06 PM, Kevin Chadwick wrote: >> > On Wed, 5 Sep 2012 15:49:15 -0430 >> > Andres Perera wrote: >> > >> >> doesn't in any way justify >> >> downloading sha256 from more than one mirror from the same connection, >> >> kevin >> > >> > It does if a lower tier has been compromised and I never said from the >> > same connection. >> >> i don't think anybody is talking about such attacks. the subject has >> clearly been mitm the whole time, since it's by far the easier attack >> > > Surely that depends on the networks, if your using OpenBSD it's quite > likely the other end which is more likely mitm or compromised, which is > half my point for many reasons. I'll admit crap routers are almost > everywhere though. > > The ops mail > > "Is there any way to verify that distribution sets and packages that I > have downloaded have not been tampered with (e.g., by someone with > access to the mirror from which I downloaded them)?" that's fine and dandy, but the ssl talk ultimately set the tone given there's no infrastructure in place, wondering about who would have the private keys is premature. most likely the developers would posses the keys, and *not* the mirror maintainers, when the roles don't overlap if that's enforced from the onset, the benefit you're left with is the guarantee that you're communicating with the party they claim to be
Re: !!!!
On Wed, Sep 5, 2012 at 4:06 PM, Kevin Chadwick wrote: > On Wed, 5 Sep 2012 15:49:15 -0430 > Andres Perera wrote: > >> doesn't in any way justify >> downloading sha256 from more than one mirror from the same connection, >> kevin > > It does if a lower tier has been compromised and I never said from the > same connection. i don't think anybody is talking about such attacks. the subject has clearly been mitm the whole time, since it's by far the easier attack > > You must be one of them body language reading fools ;-) > no, the number of mirrors is never a factor. you are just copping out and if you rely on the vast amount of data to weed out attackers that wouldn't waste the bandwidth it takes to replicate an obsd mirror, you aren't considering applications that divert on layer 7. ftp-proxy is an example. make an http/ftp session to the real server and only intercept GETs you care about
Re: !!!!
On Wed, Sep 5, 2012 at 2:22 PM, Kevin Chadwick wrote: > On Wed, 5 Sep 2012 23:12:37 +0800 > Rowdy OpenBSD wrote: > >> > To the OP. When checking I choose a source mirror or two and download >> > just the SHA256. There is no sha256 for src.tgz and sys.tgz but you can >> > use ssh for the source code by getting the fingerprint once like for >> > signatures but tied to servers and not devs. >> >> Thanks for trying to help, Kevin, but there are significant weaknesses >> in your process. >> >> How do you upgrade packages? > > It really irks me when people use my name when there is no need but > I'll assume you just wanted to make clear you were responding to my > quote (above) and also assume you are not a troll this once. > > There are significant weaknesses in any process, the majority of which > occur between the build infrastructure and source providers which > OpenBSD does a very nice job of. yes, but in this case choosing one or more mirrors doesn't make a difference. the list of sanctioned mirrors is publicly available. it'd be weird if it weren't since they're intended to be public means of distribution. if i bother setting up a ftp server, i can also bother redirecting more than one ip address. the blanket statement, "there are significant weaknesses in any process", doesn't in any way justify downloading sha256 from more than one mirror from the same connection, kevin
Re: website page to fix
On Sat, Jun 30, 2012 at 4:51 PM, Ted Unangst wrote: > Somebody wants to fix something? Straighten the hell out of > anoncvs.html. > > For starters, I'm like 90% sure that all the jibber jabber about rsh vs > ssh vs pserver can die in a fire. > > The list of crypto files is a joke. > > The big block of mirrors should probably be closer to the end. > > "CVS already compresses." This is, in fact, a lie for servers that > run the opencvs server. > about compression: gnu cvs does not compress by default. it's documented in the info page and ktrace reveals that it writes the file as is to the socket (easily apparent when updating xenocara). when you specify -zn where n > 0 < 9, compression is upload only. assuming ssh does full duplex, wouldn't it be better to suggest disabling cvs compression and specifying a wrapper as CVS_RSH which enables ssh compression?
Re: Dilemma: between OpenBSD and NetBSD
i find it hard to believe you're involved in such project. "more portable", "more secure" don't mean anything unless details are involved. i mean, if it runs on your target hosts, what could "more portable" possibly mean? it's better to say: i'm trying out these two and i want a comparison. lying, saying your boss wants a bsd solution, doesn't make it seem more important! On Fri, Aug 10, 2012 at 9:17 AM, wrote: > Hi > > A client of mine asked me if I can develop a BSD project for them. I don't have much experience with BSDs, and I have been collecting some background information. > I was given the choice between OpenBSD and NetBSD. > Now, since portability is not all that important, I was oriented towards OpenBSD, which is more secure. The only problem might be the lack of certain features on OpenBSD, such as support for a modern filesystem. As I said, I don't know much about BSDs, so don't flame at me if I say something incorrect. In fact, I am asking your advice. > What I would need for my project is a filesystem that supports, at least, journaling. From what I have seen, NetBSD already has that, while OpenBSD doesn't. > Has any modern filesystem been ported to OpenBSD? I really need to know, because this issue may constitute a stumbling block to my adoption of OpenBSD. > > Thanks > > Ben J. Rafter
Re: Kernel Level Audio Next Generation
i particularly enjoy the part where an opposing spectator conflated gdm with the only way to deal with handicapped users. he also proceeded to discredit the talker by stating that he hated the handicapped, even though that couldn't possibly be inferred from the presentation thus far. not only did you fail to recognize his drama queen tactics, you're also implying that klang is the conclusion of a personal vendetta against lennart after the most boring pissing fight ever. everybody involved in that petty exchange are jokers, including the audience who somehow didn't realize they were being manipulated with a picture of a three legged puppy. On Wed, Aug 1, 2012 at 4:25 PM, Tobias Ulmer wrote: > On Tue, Jul 31, 2012 at 10:46:57PM +0300, Alexey Suslikov wrote: >> Hello misc. >> >> http://klang.eudyptula.org/ > > Heh, that's by the guy who got his ass whooped by Lennart at 27c3. His > talk made me cringe... > > After watching, you may understand why he's writing his own stuff > instead of using the awesome PulseAudio. > >> >> Just curious, why they didn't even try to evaluate OpenBSD sndio. > > Because he's a Linux fanboi, isn't that obvious? :) > >> >> An overall approach to the problem is interesting thing too >> >> Q: Why a audio system in the kernel? >> A: Because it's the only reasonable thing to do. >> >> What people think? Maybe we should write an article for wikipedia >> to make sndio more visible to rest of the world? > > I think it's pretty pointless to document an audio system that's only > available on OpenBSD. Maybe add it to the main OpenBSD article if it > isn't mentioned there already. > >> >> Regards, >> Alexey
Re: route(8) doc question
use `route get x` flags are expanded, unlike with "show" i know of at least one place where route(1) is used in scripts, /etc/netstart. if that weren't the case, i would suggest altering the output of `route -v`. i would expect the latter to also be used in scripts since manipulating routes in terms of labels is probably useful. On Wed, Aug 1, 2012 at 1:27 PM, Michael W. Lucas wrote: > Hi, > > "route show" displays flags for a route. But route(8) doesn't give me > a conversion between those flags and their meaning. route(4) lists the > flags, but in hex format and not such that I can translate "UGRS" into > anything useful. > > I found the table in src/sbin/route/show.c, so my immediate purposes > are met. But I *know* this has to be in a man page somewhere. Is it > missing? Or did I just gloss over it somewhere? > > Thanks, > ==ml > > -- > Michael W. Lucas > http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ > Latest book: SSH Mastery http://www.michaelwlucas.com/nonfiction/ssh-mastery > mwlu...@michaelwlucas.com, Twitter @mwlauthor
Re: problem in fstab
no. the equivalent to the top/systat behaviour would be to make vi spawn less and ed when 'v' is pressed, not prompt you "are you sure?" less does not work with a dumb terminal as you said. the output eventually gets garbled. if you really want that functionality, look at /.profile. every 120 moons or so, when you actually need to be single user, just source that file. that way vi and mg can be used without duplicating logic in both of them. On Thu, Jul 26, 2012 at 10:20 AM, Mo Libden wrote: > Thu, 26 Jul 2012 07:06:02 -0430 от Andres Perera : >> the problem with this logic is that there are numerous curses >> programs: less, top, systat, vi; just to name the ones i recall from >> base. > > since you top-posted, I will too. > what's the problem with top? will it bomb out if there is no TERM? > i think rather than hurrying to answer, you'd better do you homework. > yes, you lose the interactiveness, but all your mentioned programs > do work with dumb terminal no problem! > > $ echo $TERM > xterm > $ unset TERM > $ top > load averages: 0.44, 0.12, 0.04v1.my.domain 05:46:41 > 18 processes: 17 idle, 1 on processor > CPU states: 0.5% user, 0.0% nice, 7.4% system, 0.4% interrupt, 91.7% idle > Memory: Real: 7944K/35M act/tot Free: 206M Cache: 16M Swap: 0K/280M > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND > 1 root 100 452K 352K idle wait 0:01 0.00% init > 17516 root 20 3344K 2580K sleep poll 0:00 0.00% sshd > 31665 _syslogd 20 412K 712K sleep poll 0:00 0.00% syslogd > 15719 user 20 3312K 2112K sleep select0:00 0.00% sshd > 665 root 20 640K 476K idle netio 0:00 0.00% pflogd > 597 root 20 1608K 2052K idle netcon2 0:00 0.00% sendmail > 15280 user 180 740K 520K sleep pause 0:00 0.00% ksh > 28645 root 20 396K 752K idle netio 0:00 0.00% syslogd > 4803 root 20 1452K 1632K sleep select0:00 0.00% sendmail > 1977 root 30 456K 792K idle ttyin 0:00 0.00% getty > 10310 root 30 492K 800K idle ttyin 0:00 0.00% getty >44 root 20 304K 796K idle select0:00 0.00% inetd > 13251 root 20 868K 1216K sleep select0:00 0.00% sshd > 18652 root 20 308K 656K sleep kqread0:00 0.00% apmd > 9421 root 20 692K 880K idle select0:00 0.00% cron > 3016 _pflogd40 704K 312K sleep bpf 0:00 0.00% pflogd > 9936 user 280 348K 768K onproc- 0:00 0.00% top > 24414 _sndio 2 -20 488K 428K idle poll 0:00 0.00% sndiod > > > $ less /etc/motd > WARNING: terminal is not fully functional > /etc/motd (press RETURN) > > ^OpenBSD 5.2 (GENERIC) #0: Sat Jul 14 11:58:37 EEST 2012 > > Welcome to OpenBSD: The proactively secure Unix-like operating system. > > Please use the sendbug(1) utility to report bugs in the system. > Before reporting a bug, please try to reproduce it with the latest > version of the code. With bug reports, please try to ensure that > enough information to reproduce the problem is enclosed, and if a > known fix for it exists, include that as well. > ~ > ~ > $ > $ systat > > > 1 usersLoad 0.38 0.13 0.05 Fri Jul 20 05:47:04 2012 > > > $ > >> surely retrofitting them with prompts isn't an option, specially when >> having TERM unset isn't the norm >> >> On Thu, Jul 26, 2012 at 4:33 AM, Mo Libden wrote: >> > Tue, 24 Jul 2012 18:46:55 + от Alexander Polakov : >> >> * HvN [120724 17:17]: >> >> > I booted into single user mode, mounted / and /usr according to FAQ 8. >> >> > However, when I try to use vi to change fstab, it says "unknown terminal >> >> > type". Any suggestions ? >> >> >> >> export TERM=vt220 >> > >> > may be vi can be modified to ask for terminal type if it is not defined, something like the following: >> > >> > vi: unknown terminal type, please enter the type of the terminal [vt220]: _
Re: problem in fstab
the problem with this logic is that there are numerous curses programs: less, top, systat, vi; just to name the ones i recall from base. surely retrofitting them with prompts isn't an option, specially when having TERM unset isn't the norm On Thu, Jul 26, 2012 at 4:33 AM, Mo Libden wrote: > Tue, 24 Jul 2012 18:46:55 + от Alexander Polakov : >> * HvN [120724 17:17]: >> > I booted into single user mode, mounted / and /usr according to FAQ 8. >> > However, when I try to use vi to change fstab, it says "unknown terminal >> > type". Any suggestions ? >> >> export TERM=vt220 > > may be vi can be modified to ask for terminal type if it is not defined, something like the following: > > vi: unknown terminal type, please enter the type of the terminal [vt220]: _
Re: Calomel.org
On Thu, Jul 26, 2012 at 4:30 AM, Paulm wrote: >> Dynamic content & proper search would also put an end to "just wade through marc.info" fuck-offs and self-righteous RTFD when one has to "egrep -Rli serial /usr/share/man", say. Man/info pages are the ultimate /reference/, they're not meant to solve high-level problems. The FAQs are really are no FAQs at all but a gigantic snowball with floppy install instructions crucially leaving out 5 1/4" and 8" media. > > I don't understand why the floppy install option gets you so riled up. > I happen to have a couple of IBM Thinkpads from the early 2000's, > which still work quite well with the exception of unreliable cdrom > drives. So I like knowing the floppy option is there. > because ftp(1) source reads like porky pig trying to tell you about a handy tcp stream transfer protocol, only that his characteristic stutter is replaced with "#ifndef SMALL"
Re: Calomel.org
On Thu, Jul 26, 2012 at 4:33 AM, Wojciech Puchar wrote: >> I'm used to learning tech from scratch and mastering then using it but >> my work load is punishing and I would like to clean up DNS on my lan >> since the devices are just adding up too fast... > > what a problem with DNS? It is rather easy. > > I could help you on priv if you like, if you will clean up your mail and use > something that is not archived by huge corporation. Unless you use gmail > only for mailing lists. > well, marc.info and gmane don't really qualify as huge, but they're down on the archiving part. you're apparently ok with that as long as it's not "big brother". you are so counter-culture and out there.
Re: AMD Brazos C60
On Thu, Jul 26, 2012 at 5:37 AM, David Scott wrote: > The OpenBSD website says that the support for the amd64 platform > covers all versions of the AMD Athlon 64 processors and their clones. assuming it's this page: http://www.openbsd.org/amd64.html making a reference to the instruction set, not the brand > > Unfortunately I do not understand this statement. Is the AMD Brazos > C60 microprocessor covered by this statement? My guess is that not > every supported processor has "Athlon" explicitly in its name. c60 is supported, not sure about accelerated xorg drivers > > David Scott
Reminder about your invitation from Andres Genovez
LinkedIn This invitation is awaiting your response: From Andres Genovez -- (c) 2012, LinkedIn Corporation
Re: Does OpenBSD have any plan to support Netmap framework?
the comparison started against freebsd bpf's augmentations: " Zero-copy buffer mode bpf devices may also operate in the BPF_BUFMODE_ZEROCOPY mode, in which packet data is written directly into two user memory buffers by the ker- nel, avoiding both system call and copying overhead. Buffers are of fixed (and equal) size, page-aligned, and an even multiple of the page size. The maximum zero-copy buffer size is returned by the BIOCGETZMAX ioctl. Note that an individual packet larger than the buffer size is necessarily truncated. " from here the only choices are: a) that feature is out of place; netmap is a more general approach where the optimization should take place, and b) who's talking about grafted-on bpf enhancements? bpf is just the vm making filtering decisions both arguments fail on account that i only care about capturing. netmap's site offers a bridge implementation as an example -- i would think that's an area where netmap's offerings are more attractive On Fri, Jul 13, 2012 at 4:43 PM, Ted Unangst wrote: > On Fri, Jul 13, 2012 at 16:06, Andres Perera wrote: > >> you did! you explicitly said that it would be advantageous for >> programs looking to perform analysis on captured packets. for those >> programs, it turns out the placement of the filter doesn't matter > > Sure it matters. Simple example: count packets by /24. Very simple, > but you can't do it with bpf. You have to pull all the packets to > userland, and bpf is kind of slow at that. > > Not sure why I wanted to wade into this, but nobody's going to force > you to use netmap.
Re: Does OpenBSD have any plan to support Netmap framework?
On Fri, Jul 13, 2012 at 3:40 PM, Chris Cappuccio wrote: > Andres Perera [andre...@zoho.com] wrote: >> for clients (processes) that need to do trivial filtering, e.g., >> tcpdump 'ether multicast and not broadcast', it's an overhaul for >> nothing >> >> the placement of the filtering stack in the kernel is completely >> irrelevant to "how simple" it will end up. if you come up with a >> sbin/bpfd it will still have to do locking between clients, and >> present a higher level subset to be of any use >> >> i don't expect *every* application to manage the rx/tx rings directly, >> reinject when they're done >> >> to actual uses of userland packet capture, this whole situation >> resembles "wayland is not an x replacement, it just does compositing" >> > > situation? it's just a tool. what makes you think the primary users will be > the same ones who want to use BPF? > you did! you explicitly said that it would be advantageous for programs looking to perform analysis on captured packets. for those programs, it turns out the placement of the filter doesn't matter
Re: Does OpenBSD have any plan to support Netmap framework?
for clients (processes) that need to do trivial filtering, e.g., tcpdump 'ether multicast and not broadcast', it's an overhaul for nothing the placement of the filtering stack in the kernel is completely irrelevant to "how simple" it will end up. if you come up with a sbin/bpfd it will still have to do locking between clients, and present a higher level subset to be of any use i don't expect *every* application to manage the rx/tx rings directly, reinject when they're done to actual uses of userland packet capture, this whole situation resembles "wayland is not an x replacement, it just does compositing" On Fri, Jul 13, 2012 at 3:24 PM, Chris Cappuccio wrote: > Andres Perera [andre...@zoho.com] wrote: >> >> so i should move the whole filtering stack to userland... seems like a >> needless work for simple packet capture > > And I completely disagree. > > You think what the kernel does now is simple ?
Re: Does OpenBSD have any plan to support Netmap framework?
from their site:
netmap implements a special device, /dev/netmap, which is the gateway
to switch one or more network cards to netmap mode, where the card's
datapath is disconnected from the operating system.
open("/dev/netmap") returns a file descriptor that can be used with
ioctl(fd, NIOCREG, ...) to switch an interface to netmap mode. A
subsequent mmap() exports to userspace a replica of the TX and RX
rings of the card, and the actual packet buffers. Each "shadow" ring
indicates the number of available buffers, the current read or write
index, and the address and length each buffer (buffers have fixed size
and are preallocated by the kernel).
so i should move the whole filtering stack to userland... seems like a
needless work for simple packet capture
Re: Does OpenBSD have any plan to support Netmap framework?
On Fri, Jul 13, 2012 at 11:59 AM, Chris Cappuccio wrote: > But having a generic mechanism to bring network data in/out userland for analysis or manipulation, abstracted in a secure way from the kernel across multiple network card types, and "zero copy", could be very useful. The typical response to this is "well just make the slow parts of the kernel more efficient and you won't need to do this" but, especially for pcap-type applications, I think netmap _is_ the solution. talking about userland capture exclusively: is there a comparison against freebsd bpf zero copy? how is better than bpf overall? i ask because there's been a considerable amount of work put into bpf compilers so it's replacement better justify the time spent optimizing it's predecessor
Re: missing /etc/fstab
On Sun, Jul 8, 2012 at 7:41 PM, Nico Kadel-Garcia wrote: > On Sun, Jul 8, 2012 at 8:29 AM, Theo de Raadt wrote: >>> I remember some early 5.1 snapshot which installed and successfully run >>> without /etc/fstab >>> however, 5.1-RELEASE came with /etc/fstab >>> >>> it would be nice to move system from one server to another without having >>> to bother about /etc/fstab (I moved several of them due to buggy hardware). >>> is it possible to run without /etc/fstab ? is it supported configuration ? >> >> Sorry, but you are wrong. >> >> A system must have a /etc/fstab file, and it is created by the installer. > > To "move" or replicate a system to other hardware, the /etc/fstab > aneeds to be reviewed and edited for any partition layout, or it will > not be able to find the partitions for "/" or other partitions you > happen to need. Some folks get cute and do NFS or similar targets with > automounting of varous sorts, so those aren't in fstab on such > systems. I've never seen anyone using that on OpenBSD. afaik, the duid is stored on the disklabel, so if you're making images of the media there's no need to edit fstab > > I've done this sort of replicate-and-edit-config-files stunt for > roughly 20,000 hosts in my careerm, espcially 15,000 Linux hosts in > one month, so I know the approach can be much faster than installing > from normal installation media. your sites are extremely heterogeneous
Re: "Virtualizing" firewalling scenarios in one physical OpenBSD host
that's not exciting at all. maybe one day i will write a vpf device. benefits include not having to be root to check an agreed upon subset of your states, running proxies and other applications that insert rules completely non-root other details have to be worked out so that sub-pfs can't run the system out of resources, that's the main thing xoxo On Thu, Jul 5, 2012 at 10:46 AM, Henning Brauer wrote: > * Andres Perera [2012-07-04 17:42]: >> out of curiosity, how would you make pf(4) only handle rules >> pertaining to a certain anchor depending on the process that's >> interfacing with them? i ask because; e.g., pfctl -sr should only >> show rules for that client, and other pf(4) operations need to be >> equally restricted. i know that originally you said that the loading >> of the rules is not up to the client but a periodic batch job, however >> that does not match "CheckPoint VSX" > > geez, don't act so helpless, this is unix after all. > > write yourself a little wrapper that, depending on the caller/source, > enforces a pfctl -a anchorinquestion ... > > -- > Henning Brauer, h...@bsws.de, henn...@openbsd.org > BS Web Services, http://bsws.de, Full-Service ISP > Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully > Managed > Henning Brauer Consulting, http://henningbrauer.com/
