Re: Fwd: CVS: cvs.openbsd.org: src

2015-11-30 Thread Joerg Jung
On Mon, Nov 30, 2015 at 04:48:05PM -0500, Daniel Ouellet wrote:
> Even removed the table password?

Yes.
 
> NO way anymore to have difference password for emails then the system
> password without smtp-extra install?

You may want to read table(5) the section about credentials tables.
 
> I can understand may be sqlite and ldap, but as a base system having
> different password from the system was and is very useful and I do it on
> all systems.

Still possible.

> Or am I missing something or miss understand the commit?

Yes, it looks like you never used table-passwd, 
that is why it is removed.


>  Forwarded Message 
> Subject: CVS: cvs.openbsd.org: src
> Date: Mon, 30 Nov 2015 12:54:26 -0700 (MST)
> From: Joerg Jung 
> To: source-chan...@openbsd.org
> 
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   j...@cvs.openbsd.org2015/11/30 12:54:26
> 
> Modified files:
>   usr.sbin/smtpd : Makefile
> Removed files:
>   usr.sbin/smtpd : aldap.c aldap.h ber.c ber.h table_ldap.c
>table_passwd.5 table_passwd.c table_sqlite.c
>   usr.sbin/smtpd/table-ldap: Makefile
>   usr.sbin/smtpd/table-passwd: Makefile
>   usr.sbin/smtpd/table-sqlite: Makefile
> 
> Log message:
> remove table-passwd, table-sqlite, and table-ldap
> about 4k lines seldom used code
> 
> people who rely on this install mail/opensmtpd-extras
> 
> direction discussed (and agreed) with many
> 
> ok gilles



Fwd: CVS: cvs.openbsd.org: src

2015-11-30 Thread Daniel Ouellet
Even removed the table password?

NO way anymore to have difference password for emails then the system
password without smtp-extra install?

I can understand may be sqlite and ldap, but as a base system having
different password from the system was and is very useful and I do it on
all systems.

Or am I missing something or miss understand the commit?



 Forwarded Message 
Subject: CVS: cvs.openbsd.org: src
Date: Mon, 30 Nov 2015 12:54:26 -0700 (MST)
From: Joerg Jung 
To: source-chan...@openbsd.org

CVSROOT:/cvs
Module name:src
Changes by: j...@cvs.openbsd.org2015/11/30 12:54:26

Modified files:
usr.sbin/smtpd : Makefile
Removed files:
usr.sbin/smtpd : aldap.c aldap.h ber.c ber.h table_ldap.c
 table_passwd.5 table_passwd.c table_sqlite.c
usr.sbin/smtpd/table-ldap: Makefile
usr.sbin/smtpd/table-passwd: Makefile
usr.sbin/smtpd/table-sqlite: Makefile

Log message:
remove table-passwd, table-sqlite, and table-ldap
about 4k lines seldom used code

people who rely on this install mail/opensmtpd-extras

direction discussed (and agreed) with many

ok gilles



Re: Fwd: CVS: cvs.openbsd.org: src

2015-11-30 Thread Gilles Chehade
On Mon, Nov 30, 2015 at 05:45:25PM -0500, Daniel Ouellet wrote:
> On 11/30/15 4:58 PM, Joerg Jung wrote:
> > On Mon, Nov 30, 2015 at 04:48:05PM -0500, Daniel Ouellet wrote:
> >> Even removed the table password?
> > 
> > Yes.
> >  
> >> NO way anymore to have difference password for emails then the system
> >> password without smtp-extra install?
> > 
> > You may want to read table(5) the section about credentials tables.
> >  
> >> I can understand may be sqlite and ldap, but as a base system having
> >> different password from the system was and is very useful and I do it on
> >> all systems.
> > 
> > Still possible.
> > 
> >> Or am I missing something or miss understand the commit?
> > 
> > Yes, it looks like you never used table-passwd, 
> > that is why it is removed.
> 
> May be I miss used the name. Good to know.
>

yes, the name is confusing, table-passwd is not what you want.


> I was just starting to switch all my servers to use sqlite however
> because sqlite was in the base system too and it was easier to use after
> it wad configure. (:<
> 
> Oh well.
> 
> I will switch back to makemap then.
> 
> I hope I understand your explication as this being still valid:
> 
> table vusers db:/etc/mail/vusers.db
> table vdomains db:/etc/mail/vdomains.db
> 

yes, this is still valid


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg



Re: Fwd: CVS: cvs.openbsd.org: src

2015-11-30 Thread Daniel Ouellet
On 11/30/15 4:58 PM, Joerg Jung wrote:
> On Mon, Nov 30, 2015 at 04:48:05PM -0500, Daniel Ouellet wrote:
>> Even removed the table password?
> 
> Yes.
>  
>> NO way anymore to have difference password for emails then the system
>> password without smtp-extra install?
> 
> You may want to read table(5) the section about credentials tables.
>  
>> I can understand may be sqlite and ldap, but as a base system having
>> different password from the system was and is very useful and I do it on
>> all systems.
> 
> Still possible.
> 
>> Or am I missing something or miss understand the commit?
> 
> Yes, it looks like you never used table-passwd, 
> that is why it is removed.

May be I miss used the name. Good to know.

I was just starting to switch all my servers to use sqlite however
because sqlite was in the base system too and it was easier to use after
it wad configure. (:<

Oh well.

I will switch back to makemap then.

I hope I understand your explication as this being still valid:

table vusers db:/etc/mail/vusers.db
table vdomains db:/etc/mail/vdomains.db



Fwd: CVS: cvs.openbsd.org: src

2015-04-06 Thread Philip Guenther
A heads up on this commit: if you're following -current and using any
perl modules that pull in threaded libraries from packages, such as
mysql/mariadb integration via DBD::mysql, then you may want to wait
the day or so until the ports package builds have caught up with the
change.  The perl in base built against libpthread.19.0 cannot load
the mysql.so shared object linked against libpthread.18.1

Philip Guenther

-- Forwarded message --
From: Philip Guenther guent...@cvs.openbsd.org
Date: Mon, Apr 6, 2015 at 6:27 PM
Subject: CVS: cvs.openbsd.org: src
To: source-chan...@cvs.openbsd.org


CVSROOT:/cvs
Module name:src
Changes by: guent...@cvs.openbsd.org2015/04/06 19:27:07

Modified files:
lib/csu: crtbegin.c crtbeginS.c
lib/libc   : shlib_version
lib/libc/arch/alpha: SYS.h
lib/libc/arch/alpha/sys: fork.S
lib/libc/arch/amd64: SYS.h
lib/libc/arch/amd64/sys: fork.S
lib/libc/arch/arm: SYS.h
lib/libc/arch/arm/sys: fork.S
lib/libc/arch/hppa: SYS.h
lib/libc/arch/hppa/sys: fork.S
lib/libc/arch/hppa64: SYS.h
lib/libc/arch/hppa64/sys: fork.S
lib/libc/arch/i386: SYS.h
lib/libc/arch/i386/sys: fork.S
lib/libc/arch/m88k: SYS.h
lib/libc/arch/m88k/sys: fork.S
lib/libc/arch/mips64: SYS.h
lib/libc/arch/mips64/sys: fork.S
lib/libc/arch/powerpc: SYS.h
lib/libc/arch/powerpc/sys: fork.S
lib/libc/arch/sh: SYS.h
lib/libc/arch/sh/sys: fork.S
lib/libc/arch/sparc: SYS.h
lib/libc/arch/sparc/sys: fork.S
lib/libc/arch/sparc64: SYS.h
lib/libc/arch/sparc64/sys: fork.S
lib/libc/arch/vax: SYS.h
lib/libc/arch/vax/sys: fork.S
lib/libc/include: thread_private.h
lib/libc/stdlib: atexit.c
lib/libc/sys   : Makefile.inc
lib/libc/thread: Makefile.inc unithread_malloc_lock.c
lib/librthread : rthread.c rthread_fork.c rthread_libc.c
 shlib_version
regress/lib/csu/callbacks: Makefile
regress/lib/csu/callbacks/pthread_atfork: Makefile
  pthread_atfork_test.c
Added files:
lib/libc/include: atfork.h
lib/libc/sys   : w_fork.c
lib/libc/thread: atfork.c
regress/lib/csu/callbacks/pthread_atfork: expected_child.out
  expected_parent.out

Log message:
Make pthread_atfork() track the DSO that called it like atexit() does,
unregistering callbacks if the DSO is unloaded.  Move the callback
handling from libpthread to libc, though libpthread still overrides the
inner call to handle locking and thread-library reinitialization.
Major version bump for both libc and libpthread.

verification that this fixes various ports ajacoutot@
asm assistance miod@; ok millert@ deraadt@



Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-10-15 Thread David Vasek

On Mon, 18 Aug 2014, Jason Tubnor wrote:


On 2 June 2014 10:23, Ted Unangst t...@tedunangst.com wrote:



Part of the deprecation / migration process is identifying the weird
ways people use vnd and finding solutions for them. But as we've seen,
people never move forward without the occasional push.



So the most appropriate way to use vnd(4) as an encrypted container
going forward would be to lay down softraid(4) CRYPTO inside it to
achieve a like-for-like outcome or would this be over-complicating
things?  I have had success in testing this use case but I am aware it
may not be supported.


To revive this old thread again (I missed the recent post):

I tesed the same or similar (softraid(4) crypto volume on top of 
unencrypted vnd(4) device in my case) in July this year and I saw some 
kind of write amplification effect by a factor of two. The resulting 
effective writing speed was quite low. The sector size of the underlying 
hard drive was 4K bytes.


Regards,
David



Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-08-17 Thread Jason Tubnor
On 2 June 2014 10:23, Ted Unangst t...@tedunangst.com wrote:


 Part of the deprecation / migration process is identifying the weird
 ways people use vnd and finding solutions for them. But as we've seen,
 people never move forward without the occasional push.


So the most appropriate way to use vnd(4) as an encrypted container
going forward would be to lay down softraid(4) CRYPTO inside it to
achieve a like-for-like outcome or would this be over-complicating
things?  I have had success in testing this use case but I am aware it
may not be supported.



Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-06-01 Thread David Vasek

On Fri, 30 May 2014, Theo de Raadt wrote:


Robert [info...@die-optimisten.net] wrote:

On Fri, 30 May 2014 12:19:35 -0400
Ted Unangst t...@tedunangst.com wrote:

WARNING: Encrypted vnd is insecure.
Migrate your data to softraid before 5.7.


Will 5.6 softraid support block sizes other than 512 byte?

marc.info/?l=openbsd-miscm=139524543706370


There are no plans for it right now.


They way I read the original message (and please correct me if this is wrong!), 
is that something will happen in 5.7 that will disable encrypted vnd.

Which means that people with recent internal/external HDs, that use 4k blocks, 
will have a problem.

(Some disks allow you to use jumper settings for 512b, but not all external 
ones)



Wow, don't know where you got that from.  Sometimes it is just a simple
explanation.


Could you please provide a little bit more information? What causes 
encrypted vnd to be insecure and what will happen to vnd(4) before 5.7 if 
it isn't removal of crypto?


Also, are there any options remaining to encrypt non-512-byte/sector 
devices, data on NFS filesystems (NAS boxes) and removable/backup media 
other than hard drives (or that pretend to be hard drives)?


Thank you.

Regards,
David



Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-06-01 Thread Theo de Raadt
 Could you please provide a little bit more information? What causes 
 encrypted vnd to be insecure

Ted went a bit far; it is unusual for him to be melodratic.

Basically -- less than state of the art crypto.

 and what will happen to vnd(4) before 5.7 if it isn't removal of crypto?

You persist in reading too much into things.



Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-06-01 Thread Ted Unangst
On Sun, Jun 01, 2014 at 11:37, Theo de Raadt wrote:
 Could you please provide a little bit more information? What causes 
 encrypted vnd to be insecure
 
 Ted went a bit far; it is unusual for him to be melodratic.
 
 Basically -- less than state of the art crypto.

You would never use blowfish-cbc (with a 64-bit blocksize) for disk
encryption today. You can probably find a wiki page somewhere with
details, but the reality is most people aren't capable of assessing
whether this is secure enough.

Part of the deprecation / migration process is identifying the weird
ways people use vnd and finding solutions for them. But as we've seen,
people never move forward without the occasional push.



Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-05-31 Thread Ted Unangst
On Fri, May 30, 2014 at 19:45, Jonathan Thornburg wrote:
 What will be the right way to achieve such a nested-encryption setup
 once encrypted vnd goes away?  Is/will it be safe (i.e., free from
 data corruption, deadlock, or other kernel badness) to nest softraid
 crypto volumes?

Short answer: it should be.

Long answer: if it's not, it would be better to know about problems
now rather than later, no?



encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-05-30 Thread Ted Unangst
If you are using encrypted vnd (vnconfig -k or -K) you will want to
begin planning your migration strategy.


-- Forwarded message --
From: Ted Unangst t...@cvs.openbsd.org
Date: Fri 2014/05/30 10:14 -06:00
Subject: CVS: cvs.openbsd.org: src
To: source-chan...@cvs.openbsd.org

CVSROOT:/cvs
Module name:src
Changes by: t...@cvs.openbsd.org2014/05/30 10:14:19

Modified files:
sbin/mount_vnd : mount_vnd.c 

Log message:
WARNING: Encrypted vnd is insecure.
Migrate your data to softraid before 5.7.



Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-05-30 Thread Robert
On Fri, 30 May 2014 12:19:35 -0400
Ted Unangst t...@tedunangst.com wrote:
 WARNING: Encrypted vnd is insecure.
 Migrate your data to softraid before 5.7.

Will 5.6 softraid support block sizes other than 512 byte?

marc.info/?l=openbsd-miscm=139524543706370

kind regards,
Robert



Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-05-30 Thread Chris Cappuccio
Robert [info...@die-optimisten.net] wrote:
 On Fri, 30 May 2014 12:19:35 -0400
 Ted Unangst t...@tedunangst.com wrote:
  WARNING: Encrypted vnd is insecure.
  Migrate your data to softraid before 5.7.
 
 Will 5.6 softraid support block sizes other than 512 byte?
 
 marc.info/?l=openbsd-miscm=139524543706370

There are no plans for it right now.



Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-05-30 Thread Robert
On Fri, 30 May 2014 11:14:40 -0700
Chris Cappuccio ch...@nmedia.net wrote:

 Robert [info...@die-optimisten.net] wrote:
  On Fri, 30 May 2014 12:19:35 -0400
  Ted Unangst t...@tedunangst.com wrote:
   WARNING: Encrypted vnd is insecure.
   Migrate your data to softraid before 5.7.
  
  Will 5.6 softraid support block sizes other than 512 byte?
  
  marc.info/?l=openbsd-miscm=139524543706370
 
 There are no plans for it right now.

They way I read the original message (and please correct me if this is wrong!), 
is that something will happen in 5.7 that will disable encrypted vnd.

Which means that people with recent internal/external HDs, that use 4k blocks, 
will have a problem.

(Some disks allow you to use jumper settings for 512b, but not all external 
ones)



Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-05-30 Thread Theo de Raadt
  Robert [info...@die-optimisten.net] wrote:
   On Fri, 30 May 2014 12:19:35 -0400
   Ted Unangst t...@tedunangst.com wrote:
WARNING: Encrypted vnd is insecure.
Migrate your data to softraid before 5.7.
   
   Will 5.6 softraid support block sizes other than 512 byte?
   
   marc.info/?l=openbsd-miscm=139524543706370
  
  There are no plans for it right now.
 
 They way I read the original message (and please correct me if this is 
 wrong!), is that something will happen in 5.7 that will disable encrypted vnd.
 
 Which means that people with recent internal/external HDs, that use 4k 
 blocks, will have a problem.
 
 (Some disks allow you to use jumper settings for 512b, but not all external 
 ones)


Wow, don't know where you got that from.  Sometimes it is just a simple
explanation.



Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-05-30 Thread Jonathan Thornburg
In message  http://marc.info/?l=openbsd-miscm=140146687910205w=1,
Ted Unangst wrote:
 If you are using encrypted vnd (vnconfig -k or -K) you will want to
 begin planning your migration strategy.
[[...]]
 WARNING: Encrypted vnd is insecure.
 Migrate your data to softraid before 5.7.

Once this transition happens, what will be the right way to achieve
nested crypto volumes?

That is, with present-day OpenBSD I can have the following:

/home is a softraid-crypto filesystem
managed with 'bioctl -c C' via passphrase #1

/home/me/very-secret is a vnd-crypto filesystem
backed by the files  /home/me/very-secret-storage.{salt,data}
managed with 'vnconfig -c -K' via passphrase #2

/home/me/other-secret is a vnd-crypto filesystem
backed by the files  /home/me/other-secret-storage.{salt,data}
managed with 'vnconfig -c -K' via passphrase #3

What will be the right way to achieve such a nested-encryption setup
once encrypted vnd goes away?  Is/will it be safe (i.e., free from
data corruption, deadlock, or other kernel badness) to nest softraid
crypto volumes?

ciao,

-- 
-- Jonathan Thornburg [remove -animal to reply] 
jth...@astro.indiana-zebra.edu
   Dept of Astronomy  IUCSS, Indiana University, Bloomington, Indiana, USA
   There was of course no way of knowing whether you were being watched
at any given moment.  How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork.  It was even conceivable
that they watched everybody all the time.  -- George Orwell, 1984