gmane.comp.misc.xvendor

"going public"

Hi,

I'd like to revitalize this list.  Two of the things I'd like to do are:

1. Make the xvendor archive public on the web, with e-mail addresses
obfuscated.  This will apply to past messages as well (there are 60 of
them so far, this one is the 61st).  Initially, I'd host the archive on
the Openwall website only, with full control over how addresses are
obfuscated, etc.  Submitting the list to third-party archives, some of
which have far more advanced web interfaces, may be done later.

2. Describe xvendor on a public website - including purpose and policy
of the list.  I am not sure what website this should be on; maybe I'll
just put the info somewhere on the Openwall website for lack of a better
place (that would actually receive visitors).

Note that right now the list is not pre-moderated - there's neither
subscription nor message moderation.  Perhaps this will have to change
in a while after "going public".

Comments?  Objections?

--

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15  fp: B3FB 63F4 D7A3 BCCC 6F6E  FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments

headers

Solar Designer | 17 Apr 06:13

CLK_TCK

Hi,

CLK_TCK has been obsolescent for years, yet many programs (including
some of mine) continued to use it - until very recently.  glibc 2.4 no
longer defines CLK_TCK by default.

Unfortunately, what most package maintainers appear to be doing is
replace uses of CLK_TCK with CLOCKS_PER_SEC.  This is wrong.  CLK_TCK is
for times(), whereas CLOCKS_PER_SEC is for clock().  These can
actually be different values (100 vs. 1000000 is a practical example) -
although often they're the same, meaning that the problem might not be
noticed on the maintainer's system.

The fix I've used for my own programs is as follows:

#include <unistd.h>

long clk_tck;

#if defined(_SC_CLK_TCK) || !defined(CLK_TCK)
	clk_tck = sysconf(_SC_CLK_TCK);
#else
	clk_tck = CLK_TCK;
#endif

...then replace all uses of CLK_TCK with clk_tck.  This takes into
consideration the fact that _SC_CLK_TCK or CLK_TCK might be an enum
rather than a cpp macro (although many systems define these in both
ways, which is fine).  If neither is defined as a cpp macro,
_SC_CLK_TCK is preferred.

(Continue reading)

headers

Solar Designer | 6 Nov 12:24

procmail mailbox truncation bug

Hi,

There's a really nasty bug in procmail, both 3.15.2 and 3.22 are affected.

The bug is basically that procmail, when running into a disk quota or a
full partition, would truncate the mailbox file back to its prior size
_after_ releasing the lock.  This has resulted in numerous mailbox
corruptions on a mail server I co-administer and a week ago I managed to
reproduce this on purpose (with several instances of procmail being the
only software accessing the mailbox).  After my fix, I am no longer
able to reproduce this and there have been no further mailbox corruptions
during this week, so the fix appears to work.

The patch can be found in our CVSweb:

http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/procmail/

It's procmail-3.22-owl-truncate.diff

No, it's not dirty, it just follows procmail's original coding style.
No added gotos, sorry.

The official fix might need to be slightly different to not rely on
ftruncate().

--

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments

(Continue reading)

headers

Solar Designer | 20 Oct 19:42

obfuscating e-mails in RPM specs

Hi,

We're about to start obfuscating e-mail addresses in our RPM spec files,
and we intend to update all of our existing specs accordingly.

The syntax we might use is this:

* Sat Sep 24 2005 Solar Designer <solar at owl.openwall.com> 3.6.1p2-owl15

My questions are:

1. Are others doing the same?  What syntax is being used?

2. Is this known to break any software processing spec files or RPMs?
In particular, I guess the extra spaces might break the separation of
fields, so should they be avoided?  Maybe use dashes instead?

3. Is it even worthwhile to try to come up with a common syntax for this?

Thanks,

--

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments

headers

Solar Designer | 13 Jun 05:46

Fwd: RFC: Free Software Hardware Compatibility - Centralised DB

Hi,

I am forwarding this in here with Zenaan's permission.  Zenaan is now
subscribed to xvendor too, so comments on the need for and feasibility
of his proposal may be posted in here.  Detailed discussion of actual
implementation of his proposal should, however, occur on its separate
mailing list (to be created).

-- 
/sd

----- Forwarded message from Zenaan Harkness <zen@...> -----

Subject: [Fwd: RFC: Free Software Hardware Compatibility - Centralised DB]
From: Zenaan Harkness <zen@...>
To: partner@..., info@...
Cc: feedback@..., sales@.../
X-Mailer: Ximian Evolution 1.4.6 
Date: Fri, 11 Jun 2004 07:37:08 +1000

-----Forwarded Message-----
> From: Zenaan Harkness <zen@...>
> To: hardware@..., info@...,
steve@...,
bcollins@...,
esr@..., PWCS@...,
techline@...,
sac@...,
press@...,
info@..., netbsd-help@...

(Continue reading)

headers

Solar Designer | 9 Jun 01:04

Openwall CVSweb server available

Hi,

This is to let others know that our software and patches are now also
available for review and export into other projects via CVSweb:

	http://cvsweb.openwall.com

This has the entire Openwall GNU/*/Linux (Owl) CVS tree including all
of our patches to whatever software we package and indeed our own
pieces of software which are now maintained as a part of Owl but are
also made available separately.

Of course, we also continue to maintain an anonymous CVS server
supporting the CVS pserver protocol and the CVS server protocol over
SSH, and obviously we continue to make our releases and snapshots of
Owl available through the FTP mirrors.  All of these ways to obtain
Owl and thus also our other software are listed on this web page:

	http://www.openwall.com/Owl/DOWNLOAD.shtml

A related topic for discussion: how do you defend your CVSweb servers
from automated crawlers and especially from e-mail address harvesters?
robots.txt and robots meta tag only help against the polite ones.

--

-- 
Alexander Peslyak <solar@...>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments

(Continue reading)

headers

Solar Designer | 28 Feb 22:32

OpenSSL soname

Hi,

We're about to move from OpenSSL 0.9.6* to 0.9.7* (finally), and the
previously postponed question of what soname's to use for OpenSSL's
shared libraries arises again.

Please correct me if I am wrong about any of the following:

As far as I understand, OpenSSL did not officially support building of
shared libraries until not so long ago (until 0.9.6?), yet there were
packages of OpenSSL for particular Linux distributions already in the
0.9.5 days which built shared libraries.

Those 0.9.5 and early 0.9.6 packages happened to use soname's ending
in ".0", essentially permitting the dynamic linker to use the same
shared libraries for applications linked against any 0.* version of
OpenSSL, up to the moment when...

OpenSSL 0.9.6-with-some-letter (don't remember which exactly) changed
the default soname to include all three components of the version
number, to emphasize that the OpenSSL team does not guarantee binary
compatibility between OpenSSL releases.  (What about patchlevels?)

Red Hat was using their own scheme for soname's in their OpenSSL
packages (in Red Hat Linux), as described in openssl.spec:

# 0.9.5a soversion = 0
# 0.9.6  soversion = 1
# 0.9.6a soversion = 2
# 0.9.6c soversion = 3

(Continue reading)

headers

Martin Schulze | 23 Feb 12:07

Warning: man-pages became non-free

Hi,

this is just a warning for those of you who shipt Free Software that
is not contaminated by non-free components.  The man-pages project
became inherently non-free as of version 1.65 by the inclusion of
POSIX manpages.  It's license (not included in the package, though)
permits redistribution but no modifications, which is not compatible
with any idea of Free Software.

Please see <http://linuxpr.com/releases/6599.html> for an official
announcement of The Open Group and IEEE.

For Debian I'm stripping the non-free POSIX components off of man-pages
and repackage it.  Thank got the manpages are collected in three
directories distinct from the rest of man-pages, so stripping is not
too hard.

There's also a little thread on the debian-legal list, where I hoped
that people would disagree with me.
http://lists.debian.org/debian-legal-0402/msg00190.html

Regards,

	Joey

--

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

headers

Andreas | 15 Dec 16:36

Berkeley DB versions

Hi all, I hope this list is still alive and with subscribers :)

I was wondering what all vendors are doing regarding this topic: all
the different berkeley db versions lying out there.

We, for example, have:
1.85
2.4.14
3.1.17
3.3.11
4.0.14
4.1.25
4.2.52

Prior to db 4, it's sort of a mess, with different naming schemes for
the dynamic libraries and include files.

Starting with DB4 (I obsoleted db < 4 for now, more on it later), I'm
using /usr/include/db{4,4.1,4.2} for the include files and I'm experimenting
with /usr/lib/db4.2 for the 4.2 libraries. Here are some thoughts that are
going through my head:

- -ldb: many aplications rely on the concept of a "default db library". I
asume this is for historic reasons. I would like to get rid of this if possible. Same
for /usr/include/db.h, which is usually a symlink to /usr/include/db<version>/db.h.
Applications which use #include <db.h> will still build if one adjusts the include
path, which is what I'm doing.

- /usr/lib/libdb-4.so: argh, it's the same name for db4, db4.1 and db4.2. I used
to remove these ambiguous files from our packages, but if I decide to go the

(Continue reading)

headers

Dmitry V. Levin | 22 Sep 17:15

Q: strace upstream maintainer

Greetings!

Does anybody know who is real strace upstream maintainer nowdays?
Tried to contact both Wichert and Roland but got no responce yet...

--

-- 
ldv

headers

Seth Arnold | 9 Apr 18:36

openssl blinding and threads?

Yesterday, I saw someone on IRC mention that Red Hat's OpenSSL update
(either to turn on blinding, or the oracle fix) broke threading, backed up
with the idea that recompiling stunnel to use fork() instead of whatever
thread library it had been using, caused some problems of his to go away.

I wasn't able to drag out better information from him before he
dissapeared, but I thought I'd mention it as a heads-up, in case any of
you run into similar problems.

--

-- 
"Learning curve encryption is much more powerful than
eliptical curve encryption." -- Alan Olsen

Mon	Tue	Wed	Thu	Fri	Sat	Sun

				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31