Need an advice about DHCP IPv6 server software

[Denis]

Hi All,

I have working OpenBSD based IPv4 router, but now need to add IPv6
functionality to the same router box with keeping all IPv4 services.

I've set aliases with IPv6 addresses for all the adapters in
/etc/hostname.if  and added filtering rules for IPv6 to PF.

Stuck with IPv6 DHCP server piece of software. Which one do I need to
have IPv6 DHCP server functionality? The best solution is to use
implemented into OpenBSD, no packaged one.

Please recommend some. Any examples will be useful too.

Thank you.

 

 

How to make ProtonMail compatible with misc@ Re: Do not give-up on marketing

[Joseph Mayer]

Here is how to make ProtonMail compatible with misc@:

Click "Settings" up to the right.

Click the "Appearance" tab in the menu.

Under the "Composer mode" section there's a dropdown with two options, it's 
preset to "Normal".

Switch it to "Plain Text".


This email was sent from ProtonMail. I presume it's in the format everyone 
wants.


Yeah you can make the misc@ ML server filter away emails with hostile 
formatting.

>>On 3 Dec 2017, at 08:46, Rupert Gallagher r...@protonmail.com wrote:
>>Finally, the truth behind the aggressive behaviour against me. Some of you 
>>cannot read protonmail posts because you read the list through a mail archive 
>>with a substandard implementation of mime encoding. Well, fuck you and your 
>>mail archive. Upgrade, or die slowly.
>>Sent from ProtonMail Mobile
>>>On Sun, Dec 3, 2017 at 13:59, Stuart Henderson s...@spacehopper.org wrote:
>>>On 2017-12-03, Mihai Popescu wrote: >> Just filter @protonmail.com (I have 
>>>it for message-id and in-reply-to), you'll have a more pleasant > 
>>>misc@-reading experience. > > I use to read lists in marc.info. > It is a 
>>>little bit off topic, but I dare to ask: what combination are > you using, 
>>>like email client and misc@ configuration( i.e, daily > digest, individual 
>>>emails, etc.)? > > I am sorry for the off topic. For most lists I just use 
>>>mutt. For noisier ones like misc I use slrn (via news.gmane.org) as the 
>>>filtering in usenet clients is a bit better. @gmail.com>
>>>
>>> You've been told your email client
>>> doesn't confirm to the netiquette of
>>> this mailing list numerous times.
>>> You obviously don't care, because
>>> you keep using it, so if anyone's
>>> being rude it's you.
>>>

Re: TRIM on SSD

[tinkr]

> On 2017-12-05 17.26.27 -0500, Rupert Gallagher wrote:
>> Sent from ProtonMail Mobile
> 
> When you implement the patch that adds TRIM you might want to build off
> the work already done and lessons learned. I only spent a few seconds
> searching so you might find more:
> 
> https://www.tedunangst.com/flak/post/lessons-learned-about-TRIM
> https://marc.info/?l=openbsd-misc=144738028409142=2
> https://marc.info/?l=openbsd-misc=143453951901714=2
> https://marc.info/?l=openbsd-misc=148908000202884=2

Oh, that's an interesting article by Unangst.

If TRIM would be implemented someday, one thing that would be neat would be 
that crypto and other softraid would propagate the TRIM. That would be a nice 
combination between wear level resiliency and disk data safety.

AFAIK some other disk crypto solutions do that. The feature comes under names 
such as "encrypt used space only".

help updating EHCI driver

[Paul B. Henson]

I'm trying to port some quirks for AMD USB chipsets from other operating
systems to OpenBSD to hopefully resolve issues I am having with the pc
engines APU3 EHCI ports, as they seem to work fine on those systems.
I've got a pretty rough draft of one of them, which disables low-power
mode during transfers, but would appreciate a little clarification on
device I/O as I'm not generally a device driver developer.

Under Linux, the kernel uses absolute addresses when it's doing port I/O
to a device, so that's what I am referencing in their implementation. In
OpenBSD I see that a driver maps a handle to a region of memory and then
uses offsets from the base of that region for port I/O. It looks like
the EHCI driver code has already mapped that region and the handle is
available for me to use, but I don't see where that mapping was made or
how to figure out what the base was in order to turn the absolute
addresses I have into appropriate offsets to use with the openbsd API?

Then, for some of the chipsets, in addition to poking at the USB device
itself to twiddle the low-power mode, you also have to muck with the
northbridge configuration. I think I gathered the device information,
although I don't know that was the correct way to do so; but I need to
map the I/O region for it to a handle so I can modify it. If a driver for
one device needs to write to a different device is it supposed to call
bus_space_map on its own to get a mapping, or can it somehow get access
to the existing one already in place for that device?

Finally, low power mode is supposed to be disabled whenever there are
asynchronous transfers occurring, and then re-enabled once they
complete. I'm not sure I've put the calls in the right place, and I know
I haven't handled the case where transfers fail or are canceled  rather
than complete.

The other quirk involves never having an empty frame list; I have
implemented the logic to detect when that is required, but haven't even
come close to wrapping my head around actually implementing the quirk
itself.

In any case, here is my current laughable diff, advice and corrections
most appreciated.


Index: pci/ehci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/ehci_pci.c,v
retrieving revision 1.30
diff -u -p -r1.30 ehci_pci.c
--- pci/ehci_pci.c  20 Jul 2016 09:48:06 -  1.30
+++ pci/ehci_pci.c  6 Dec 2017 02:46:24 -
@@ -66,6 +66,8 @@ struct ehci_pci_softc {
 };
 
 int ehci_sb700_match(struct pci_attach_args *pa);
+int ehci_amd_pll_quirk_match(struct pci_attach_args *pa);
+int ehci_amd_pll_quirk_match_nb(struct pci_attach_args *pa);
 
 #define EHCI_SBx00_WORKAROUND_REG  0x50
 #define EHCI_SBx00_WORKAROUND_ENABLE   (1 << 3)
@@ -111,6 +113,7 @@ ehci_pci_attach(struct device *parent, s
char *devname = sc->sc.sc_bus.bdev.dv_xname;
usbd_status r;
int s;
+   struct pci_attach_args amd_pa;
 
/* Map I/O registers */
if (pci_mapreg_map(pa, PCI_CBMEM, PCI_MAPREG_TYPE_MEM, 0,
@@ -131,6 +134,86 @@ ehci_pci_attach(struct device *parent, s
 
/* Handle quirks */
switch (PCI_VENDOR(pa->pa_id)) {
+   case PCI_VENDOR_AMD:
+   /* AMD errata indicates 8111 chipset EHCI is broken */
+   if (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_8111_EHCI) {
+   printf("%s: AMD 8111 EHCI broken, skipping", devname);
+   goto disestablish_ret;
+   }
+   if (pci_find_device(_pa, ehci_amd_pll_quirk_match)) {
+   sc->sc.amd_chipset.rev = PCI_REVISION(amd_pa.pa_class);
+   if (PCI_PRODUCT(amd_pa.pa_id) == 
PCI_PRODUCT_ATI_SBX00_SMB) {
+   if (sc->sc.amd_chipset.rev >= 0x10 &&
+   sc->sc.amd_chipset.rev <= 0x1f)
+   sc->sc.amd_chipset.gen = 
AMD_CHIPSET_SB600;
+   else if (sc->sc.amd_chipset.rev >= 0x30 &&
+sc->sc.amd_chipset.rev <= 0x3f)
+   sc->sc.amd_chipset.gen = 
AMD_CHIPSET_SB700;
+   else if (sc->sc.amd_chipset.rev >= 0x40 &&
+sc->sc.amd_chipset.rev <= 0x4f)
+   sc->sc.amd_chipset.gen = 
AMD_CHIPSET_SB800;
+   else
+   sc->sc.amd_chipset.gen = 
AMD_CHIPSET_UNKNOWN;
+
+   }
+   else if (PCI_PRODUCT(amd_pa.pa_id) == 
PCI_PRODUCT_AMD_HUDSON2_SMB) {
+   if (sc->sc.amd_chipset.rev >= 0x11 &&
+   sc->sc.amd_chipset.rev <= 0x14)
+   sc->sc.amd_chipset.gen = 
AMD_CHIPSET_HUDSON2;
+   else if (sc->sc.amd_chipset.rev >= 0x15 &&
+

Re: New default setup for touchpads in X

[Base Pr1me]

Honestly, my issues are minimal in regards to the tap-to-click activating during 
typing. If I'm typing in bed or at a awkward angle exacerbates it, but it's not 
a huge issue. "Edge Zones" might be just the ticket. I always found the 
syndaemon a bit odd, anyway, and had to play with the timing to make it feel 
like it worked correctly.


I'll keep an eye out for your future posts and report any (and then when I went 
to type anomalies, the tap-to-click got me, even though I'm not at an odd angle) 
anomalies. So, parenthetically, edge zones might be the ticket! :D


On 12/5/17 5:23 PM, Ulf Brosziewski wrote:

Up to now, I have only vaguely considered that, and there are
some other things pending.  However, if many users will be
missing that option, my priorities might change ;-)  Would
"edge areas" be an alternative for you?  synaptics(4) has an
option for defining edge zones.  A touch that starts there does
not trigger pointer movement, tapping, and scrolling as long as
it hasn't left the area.  The input driver in wsmouse(4) has a
similar mechanism, what's missing up to now is a decent way to
configure it, but it can be done, and it might be a way to mitigate
the effects of accidental touches.  Of course, whether it could
help in your case depends on your habits.

On 12/06/2017 12:17 AM, Base Pr1me wrote:

Are there plans to have a solution to halt the touchpad when typing is
occurring, similar to what syndaemon does? Otherwise, the driver works fine
for me on ThinkPad T470s.

On Tue, Dec 5, 2017 at 3:59 PM, Ulf Brosziewski 

Re: Integrating "safe" languages into OpenBSD?

[Adam Steen]

> The question for consideration is if microservices/unikernels approach
> is not the best combination of both worlds, e.g. having something like
> Mirage or HalVM based application/service running on top of OpenBSD in
> its VMM, that may be interesting. Unfortunately so far both supports
> IIRC just Xen.
>

Just a note on the above statements, i currently have solo5/vmm (with
lots of help from Mike L and Mike B) [1] running on OpenBSD Current
and am working towards [2] getting MirageOS [3] working too, if you
would like more information please let me know.

Cheers
Adam

[1] https://github.com/adamsteen/solo5
[2] https://github.com/Solo5/solo5/issues/206
[3] https://mirage.io/

Re: TRIM on SSD

[Mike Burns]

On 2017-12-05 17.26.27 -0500, Rupert Gallagher wrote:
> Sent from ProtonMail Mobile

When you implement the patch that adds TRIM you might want to build off
the work already done and lessons learned. I only spent a few seconds
searching so you might find more:

https://www.tedunangst.com/flak/post/lessons-learned-about-TRIM
https://marc.info/?l=openbsd-misc=144738028409142=2
https://marc.info/?l=openbsd-misc=143453951901714=2
https://marc.info/?l=openbsd-misc=148908000202884=2

Re: New default setup for touchpads in X

[Ulf Brosziewski]

Up to now, I have only vaguely considered that, and there are
some other things pending.  However, if many users will be
missing that option, my priorities might change ;-)  Would
"edge areas" be an alternative for you?  synaptics(4) has an
option for defining edge zones.  A touch that starts there does
not trigger pointer movement, tapping, and scrolling as long as
it hasn't left the area.  The input driver in wsmouse(4) has a
similar mechanism, what's missing up to now is a decent way to
configure it, but it can be done, and it might be a way to mitigate
the effects of accidental touches.  Of course, whether it could
help in your case depends on your habits.

On 12/06/2017 12:17 AM, Base Pr1me wrote:
> Are there plans to have a solution to halt the touchpad when typing is
> occurring, similar to what syndaemon does? Otherwise, the driver works fine
> for me on ThinkPad T470s.
> 
> On Tue, Dec 5, 2017 at 3:59 PM, Ulf Brosziewski > wrote:
> 
>> If you're following -current, or if you upgrade your system with the
>> next or a future snapshot, please note that the default setup for
>> touchpads in X will change.
>>
>> X will select ws(4) instead of synaptics(4) as default driver.  In a
>> configuration with ws, touchpad-specific input processing is done by
>> wsmouse(4).  Touchpad configuration parameters are made available in
>> wsconsctl(4), see
>> https://marc.info/?l=openbsd-misc=150153498920367=2
>> for some hints (the wsmouse man page is not up to date yet).
>>
>> Using synaptics(4) as input driver is still possible, it will require
>> a custom xorg.conf file.  If you already have such a file - which
>> overrides the default -, please consider giving ws a try, and help
>> us by reporting problems if it doesn't work for you.
>>
>>
> 

Re: New default setup for touchpads in X

[Base Pr1me]

Are there plans to have a solution to halt the touchpad when typing is
occurring, similar to what syndaemon does? Otherwise, the driver works fine
for me on ThinkPad T470s.

On Tue, Dec 5, 2017 at 3:59 PM, Ulf Brosziewski  wrote:

> If you're following -current, or if you upgrade your system with the
> next or a future snapshot, please note that the default setup for
> touchpads in X will change.
>
> X will select ws(4) instead of synaptics(4) as default driver.  In a
> configuration with ws, touchpad-specific input processing is done by
> wsmouse(4).  Touchpad configuration parameters are made available in
> wsconsctl(4), see
> https://marc.info/?l=openbsd-misc=150153498920367=2
> for some hints (the wsmouse man page is not up to date yet).
>
> Using synaptics(4) as input driver is still possible, it will require
> a custom xorg.conf file.  If you already have such a file - which
> overrides the default -, please consider giving ws a try, and help
> us by reporting problems if it doesn't work for you.
>
>

New default setup for touchpads in X

[Ulf Brosziewski]

If you're following -current, or if you upgrade your system with the
next or a future snapshot, please note that the default setup for
touchpads in X will change.

X will select ws(4) instead of synaptics(4) as default driver.  In a
configuration with ws, touchpad-specific input processing is done by
wsmouse(4).  Touchpad configuration parameters are made available in
wsconsctl(4), see
https://marc.info/?l=openbsd-misc=150153498920367=2
for some hints (the wsmouse man page is not up to date yet).

Using synaptics(4) as input driver is still possible, it will require
a custom xorg.conf file.  If you already have such a file - which
overrides the default -, please consider giving ws a try, and help
us by reporting problems if it doesn't work for you.

Re: TRIM on SSD

[Rupert Gallagher]

Why?

Sent from ProtonMail Mobile

On Tue, Dec 5, 2017 at 16:29, Juan Francisco Cantero Hurtado 
 wrote:

> On Tue, Dec 05, 2017 at 02:26:43AM -0500, Rupert Gallagher wrote: > A 
> production obsd is serving 50GB worth of NFS shares and hourly backups on two 
> ssds since August, and is still going strong at 550MBps over measured 
> 550--950Mbps LAN links. The same boots and runs the OS from a pSLC SD with 
> Phison controller. The ssds have a 5year warrantee, and we are doing our best 
> to stay within specs. The only concern is the lack of TRIM on the SD and the 
> NFS ssd. With TRIM, the os keeps writing on free space instead of deleting 
> and overwriting, for faster writing and uniform wearing of disk. > > Can we 
> safely enable TRIM on 6.2 now? OpenBSD doesn't support TRIM. -- Juan 
> Francisco Cantero Hurtado http://juanfra.info

.Va errno

[Jan Stary]

All annotated occurences of "errno" in intro(2) are .Va,
except this one which is .Dv - is that intended?

The others talk about the "varible" errno, this one is
an "identifier which expands to an addressable location",
whatever that means.

Jan


Index: intro.2
===
RCS file: /cvs/src/lib/libc/sys/intro.2,v
retrieving revision 1.65
diff -u -p -r1.65 intro.2
--- intro.2 5 Sep 2017 03:06:26 -   1.65
+++ intro.2 5 Dec 2017 22:01:26 -
@@ -51,7 +51,7 @@ Programs may be restricted to a subset o
 .\"
 .Sh DIAGNOSTICS
 Nearly all of the system calls provide an error number via the identifier
-.Dv errno ,
+.Va errno ,
 which expands to an addressable location of type
 .Vt int .
 The address of

Re: Do not give-up on marketing

[Sterling Archer]

> On 3 Dec 2017, at 08:46, Rupert Gallagher  wrote:
> 
> Finally, the truth behind the aggressive behaviour against me. Some of you 
> cannot read protonmail posts *because* you read the list through a mail 
> archive with a substandard implementation of mime encoding. Well, fuck you 
> and your mail archive. Upgrade, or die slowly.
> 
> Sent from ProtonMail Mobile
> 
>> On Sun, Dec 3, 2017 at 13:59, Stuart Henderson  wrote:
>> 
>> On 2017-12-03, Mihai Popescu wrote: >> Just filter @protonmail.com (I have 
>> it for message-id and in-reply-to), you'll have a more pleasant > 
>> misc@-reading experience. > > I use to read lists in marc.info. > It is a 
>> little bit off topic, but I dare to ask: what combination are > you using, 
>> like email client and misc@ configuration( i.e, daily > digest, individual 
>> emails, etc.)? > > I am sorry for the off topic. For most lists I just use 
>> mutt. For noisier ones like misc I use slrn (via news.gmane.org) as the 
>> filtering in usenet clients is a bit better. @gmail.com>

You've been told your email client
doesn't confirm to the netiquette of
this mailing list numerous times.
You obviously don't care, because
you keep using it, so if anyone's
being rude it's you.

t610 of hp runs openbsd including X

[Tuyosi T]

hi all

i recently get it about 40$.
it consumes only 15W .
so it is sutable for www server .
it iwas already installed puppy linux on flash memory by seller .

i already have 2.5 inch sata hard disk which was installed Uefi openbsd.
so i attach it to sata interface on board .

i prepare
cat /initrd/mnt/dev_save/menu.lst
# menu.lst produced by grub4dosconfig-v1.9.1
color white/blue black/cyan white/black cyan/black
#splashimage=/splash.xpm
timeout 10
default 0

title OpenBSD
chainloader (hd1,3)+1
rootnoverify (hd1,3)
boot


that is all .

regards
detail is http://openbsd-akita.blogspot.jp/2017/12/hp-t610.html
  ( written in japanese)

Re: Do not give-up on marketing

[Alfred Morgan]

Mihai Popescu  wrote:
> I use to read lists in marc.info.
> It is a little bit off topic, but I dare to ask: what combination are
> you using, like email client and misc@ configuration( i.e, daily
> digest, individual emails, etc.)?

I'm reading on marc.info using Chrome. Here's a quick tip to read the
base64 encoded emails on the web:
1. Copy full b64 text block
2. Open javascript console (ctrl+shift+J)
3. atob(``) // <-- note the backticks
4. 
5. Profit!
-- 
-alfred

Re: TRIM on SSD

[Juan Francisco Cantero Hurtado]

On Tue, Dec 05, 2017 at 02:26:43AM -0500, Rupert Gallagher wrote:
> A production obsd is serving 50GB worth of NFS shares and hourly backups on 
> two ssds since August, and is still going strong at 550MBps over measured 
> 550--950Mbps LAN links.  The same boots and runs the OS from a pSLC SD with 
> Phison controller. The ssds have a 5year warrantee, and we are doing our best 
> to stay within specs.  The only concern is the lack of TRIM on the SD and the 
> NFS ssd. With TRIM, the os keeps writing on free space instead of deleting 
> and overwriting, for faster writing and uniform wearing of disk.
> 
> Can we safely enable TRIM on 6.2 now?

OpenBSD doesn't support TRIM.


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: pcengines apu boards

[Marko Cupać]

On Mon, 4 Dec 2017 12:53:26 -0800
"Paul B. Henson"  wrote:

> > From: Marko Cupac
> > Sent: Monday, December 4, 2017 3:54 AM
> > 
> > I have just ordered one APU3b4, as I wanted to test mobile provider
> > as a backup link. I see it probably won't be any good as OpenBSD
> > router (yet), but at least I'll be able to test and give feedback.  
> 
> Assuming you're planning to use an internal Mini PCI card, unless you
> have more luck than me, it's not going to work :(. I'm hoping I will
> be able to fix the EHCI driver to be more happy with the AMD USB
> chipset, but this point I'm still fumbling with it :).

My APU3b4 has just arrived, hopefully I'll have time to install it with
OpenBSD tomorrow and send feedback.

Regards,
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: Integrating "safe" languages into OpenBSD?

[Karel Gardas]

On Sun, Dec 3, 2017 at 7:59 PM, Nicolas Schmidt
 wrote:
> Hi,
>
> I recently watched a recording of Theo's talk on pledge at EuroBSDCon 2017, 
> in which the question of memory-safe languages and their practical usefulness 
> came up. Specifically, someone in the audience criticized the approach taken 
> by OpenBSD, which (as I understand) accepts that all software is broken and 
> mitigates the damage caused by various classes of exploits through techniques 
> like ASLR, and suggested that instead one should stick to "memory safe 
> languages" to avoid these exploits altogether.
>
> As a response to this, Theo asked rhetorically "Where's ls, where's cat, 
> where's grep, and where's sort?", implying that noone so far bothered to 
> write implementations of even the basic unix utilities in such a language.
>
> This brings me to the question, what if someone actually bothered? Under what 
> conditions would you consider replacing one of the current C implementations 
> with an implementation written in another, "safer" language? Note that with 
> Cgrep and haskell-ls, there do in fact exist implementations/analogues of two 
> of the mentioned utilities in a memory safe language (Haskell).

IMHO it does not make any sense since (1) it was just rhetorical
question probably and (2) even if you do have set of base utils
written in Haskell, you would still need Haskell compiler/interpreter
and due to size it's probably a no go into the base anyway. And you
know the mantra: base should build base.

On the other hand, it'd also be a waste of energy probably since even
Haskell is high-productive language, you still compete with let's say
99% of utility code written in C. So what do you do if you need to do
a bug fix in this? Rewrite 100% in Haskell or just rewrite/write 1% of
bugfix in C? My bet is that if the question is not about a complete
rewrite than fixing in C is more productive.

Another point: look into the history. Systems usually stays written in
the language where they started. Unix -> C. Cobol -> Cobol. Windows ->
mix C/C++/ now also .Net. But you layer on top of those additional
functionality. Look into Unix(-like) and how it drives current world
of WWW and or mobile/phone/device industry. The core is still the
same. Unix- philosophy kernel written in C and on top of this some
additional functionality and/or web services.

So to me it looks like: use language of the target system if there is
a need to hack system functionality/bugfix, but let's use modern
language if building functionality on top of that. IMHO quite
evolutionary approach. The revolutionary approach or system written in
modern language like Haskell, I'm afraid this is not going to fly also
due to limited number of interested people not be able to go over
certain critical people-threshhold/mass. For Haskell specifically see
House, Kinetic or Hos.
https://wiki.haskell.org/Applications_and_libraries/Operating_system

The question for consideration is if microservices/unikernels approach
is not the best combination of both worlds, e.g. having something like
Mirage or HalVM based application/service running on top of OpenBSD in
its VMM, that may be interesting. Unfortunately so far both supports
IIRC just Xen.

Have fun!

Re: Integrating "safe" languages into OpenBSD?

[Karel Gardas]

On Tue, Dec 5, 2017 at 11:29 AM, Gareth Nelson  wrote:
> Just throwing my 2 cents in here:
> I don't think it'd be appropriate in OpenBSD base, but i'd love to get
> involved in writing a *nix environment in a "safe" language and at one

If you are not opposed to switching your tooling, then have a look at
https://www.redox-os.org/ -- OS done in Rust. Currently probably the
most viable not-in-C OS besides a tons of academic exercises.

Re: Chip cheaper than chips

[Kevin Chadwick]

On Tue, 05 Dec 2017 01:41:12 -0500


> industrial SDHC with pSLC
> 
> https://swissbit.com/products/nand-flash-products/cards/sd-memory-cards/

Glad you know atleast, I guess size is everything for you at that cost.
Personally I want SATA for > 1TB at low cost. It is quite funny that
the HDD is bigger than the CPU board though ;)

Re: Chip cheaper than chips

[Kevin Chadwick]

On Tue, 05 Dec 2017 01:44:03 -0500


> Article on how to disable the management engine, if you have it and
> are afraid of it.
> 
> http://blog.ptsecurity.com/2017/08/disabling-intel-me.html?m=1

Yep but this is meant for DOD to replace the functionality with it's
own micro. They state they have no idea how reliable this will be?

Re: Integrating "safe" languages into OpenBSD?

[Gareth Nelson]

Just throwing my 2 cents in here:
I don't think it'd be appropriate in OpenBSD base, but i'd love to get
involved in writing a *nix environment in a "safe" language and at one
point was thinking of building a linux distro where all the core tools are
in Python - more for the fun of it than anything serious, but if anyone
wants to get together to do this kind of project with a focus on security
and safety i'd love to get back to it.

I've also experimented (as all serious coders have) with my own lisp
variant, and would love to make that the basis of a small set of unix tools
with quick compilation. Reply off-list if interested.

On Tue, Dec 5, 2017 at 9:47 AM,  wrote:

> On Mon, 4 Dec 2017 16:24:52 +0100
> Nicolas Schmidt  wrote:
>
> > So they wrote a program that was a) shitty and b) memory-safe? Those are
> two orthogonal dimensions. Also, the anecdotal evidence that safe languages
> attract bad programmers does not imply that using safe languages is bad: a
> good programmer won't suddenly commit such atrocities as you mentioned,
> just because they use a safe language.
>
> A good programmer won't even need these languages in the first
> place. Case in point, the entire OpenBSD dev team. :)
>
> > Finally, your example probably speaks more about business practices than
> about safe programming languages. If you want to compare Java to a
> non-memory-safe language, you should compare it to one that is also
> designed *for* (instead of *by*) programmers, like Cobol.
>
> It goes back to the point I make though, that these languages encourage
> this kind of behavior by promoting a false sense of security, hence
> complacency.
>
>

Re: Multicast in OSPF with shared interface addresses

[Dimitris Papastamos]

On Sun, Dec 03, 2017 at 04:01:35PM -0500, Scott Nicholas wrote:
> I joined a VPN network (dn42) to learn BGP and such and decided to do
> so with OpenBSD, which I'm also learning. Most peers are Linux
> machines and they re-use their address on each VPN tunnel as a /32. I
> have been successful doing the same until I decided I needed ospf for
> my internal routes.
> 
> openospfd sets the interface (identified only by its IP) as the
> multicast source. Since several tunnels have that address, it sets it
> incorrectly. A brief look at Linux headers show that their newer
> ip_mreqn struct includes an interface index since Linux 2.2. Perhaps
> this is a useful inclusion in the OpenBSD kernel so that userland can
> pick the interface correctly?
> 
> For now I've worked around this by assigning /31 aliases in
> 192.168.0.0/16 to the interfaces. But I'm curious what others are
> doing that use OpenBSD as a router, as it's all fairly new to me. I'm
> reading that OSPF could also have unicast neighbors setup, but
> OpenOSPFd doesn't have this feature.

I have also experienced the same thing and worked around it using /30s
but would be nice to know how to approach this properly.

Re: Chip cheaper than chips

[Karel Gardas]

On Tue, Dec 5, 2017 at 7:44 AM, Rupert Gallagher  wrote:
> Article on how to disable the management engine, if you have it and are 
> afraid of it.
>
> http://blog.ptsecurity.com/2017/08/disabling-intel-me.html?m=1
>

And do you really trust that after this your CPU/platform is fully
functional yet no *bits* of ME are working so there is really no
remote hole in the platform?

Re: Integrating "safe" languages into OpenBSD?

[bytevolcano]

On Mon, 4 Dec 2017 16:24:52 +0100
Nicolas Schmidt  wrote:

> So they wrote a program that was a) shitty and b) memory-safe? Those are two 
> orthogonal dimensions. Also, the anecdotal evidence that safe languages 
> attract bad programmers does not imply that using safe languages is bad: a 
> good programmer won't suddenly commit such atrocities as you mentioned, just 
> because they use a safe language.

A good programmer won't even need these languages in the first
place. Case in point, the entire OpenBSD dev team. :)

> Finally, your example probably speaks more about business practices than 
> about safe programming languages. If you want to compare Java to a 
> non-memory-safe language, you should compare it to one that is also designed 
> *for* (instead of *by*) programmers, like Cobol.

It goes back to the point I make though, that these languages encourage
this kind of behavior by promoting a false sense of security, hence complacency.

GPD Pocket runs X via wsfb driver, with hardware rotation. Intel HD 405 unsupported.

[Joseph Mayer]

Hi,

The GPD Pocket has Intel HD 405 graphics, which is not supported ( 
http://man.openbsd.org/intel.4 ).

Furthermore, the laptop display is rotated 90 degrees by default, so the text 
console looks messed up: a small blob of text in the middle of the display, 
that is rotated 90 degrees.

However, X works fine when run with the "wsfb" (UEFI framebuffer) driver, with 
this /etc/X11/xorg.conf , and obviously with "xterm -fa fixed -fs 19":

Section "Device"
 Identifier "Card0"
 Driver "wsfb"
 Option "Rotate" CW"
 EndSection


I guess this is fair enough, and the only relevant thing to add here would be 
larger font and screen rotation in the text console.


Now that I mention there anyhow though, I'd also like to ask if there are any 
plans to support the Intel HD 405 at some point?


Thanks and hope the xorg.conf helps someone.

Joseph