Re: question to package maintainers

[Tim Hume]

Having OpenSSL and LibreSSL living together on the same system seems 
reasonable. Surely name conflicts can be worked around somehow?

Out of curiosity, does anyone know how many people run OpenSMTP on the 
offending systems compared to OpenBSD?

Cheers,

Tim Hume. 

> On 24 Dec 2015, at 03:06, Gilles Chehade  wrote:
> 
>> On Wed, Dec 23, 2015 at 07:56:02AM -0800, Richard wrote:
>>> On Wed, 23 Dec 2015, Gilles Chehade wrote:
>>> 
>>> What I'm wondering is if there's any reason that would prevent RHEL, for
>>> example, to package LibreSSL in the same way that libasr was packaged so
>>> that OpenSMTPD could specifically depend on it.
>>> 
>>> The system would keep its default SSL library.
>> 
>> Library name collision
>> --
>> Libasr is a unique library name on Linux as far as I know and there is no
>> problem installing it.
>> 
>> LibreSSL contains library names libcrypto and libssl which collide with
>> the identical names in OpenSSL on most Linux systems.
>> 
>> Can the libcrypto and libssl library names in LibreSSL be changed?
>> 
>> Maybe they can change to liblibrecrypto and liblibressl?
>> 
>> LibreSSL also uses library libtls.
>> Is libtls unique in Linux?
>> 
>> If not maybe it can change to liblibretls?
>> 
>> Changing the library names allows LibreSSL and OpenSSL to exist
>> side by side on any Linux system.
> 
> I'm well aware of that, but that's precisely what I'm suggesting:
> 
> If the ONLY reason keeping from depending on LibreSSL is that there is a
> problem currently with the library name, then we can take a step back to
> think of a solution that would solve this and help us move forward.
> 
> 
> -- 
> Gilles Chehade
> 
> https://www.poolp.org  @poolpOrg
> 
> -- 
> You received this mail because you are subscribed to misc@opensmtpd.org
> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
> 

--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: question to package maintainers

[Gilles Chehade]

On Thu, Dec 24, 2015 at 07:25:36PM +1100, Tim Hume wrote:
> Having OpenSSL and LibreSSL living together on the same system seems 
> reasonable. Surely name conflicts can be worked around somehow?
> 

That's my point ;-)


> Out of curiosity, does anyone know how many people run OpenSMTP on the 
> offending systems compared to OpenBSD?
> 

Nope, I'd say half users are OpenBSD, half are Linux/FreeBSD if my mails
are anything close to reality.

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: question to package maintainers

[Gilles Chehade]

Just before we dive further into this thread, I'd like to clarify that the
reason for this debate is really to help establish a strategy forward, not
a way to push for a change next week disregarding packagers.

I want to be sure I understand the limiting factors here and there, so the
change CAN happen (it is going to sooner or later), but in a way that does
not hurt users and that packagers can cope with.



On Thu, Dec 24, 2015 at 04:34:34AM +0600, Denis Fateyev wrote:
> On Wed, Dec 23, 2015 at 9:16 PM, Gilles Chehade  wrote:
> 
> >
> > What I'm wondering is if there's any reason that would prevent RHEL, for
> > example, to package LibreSSL in the same way that libasr was packaged so
> > that OpenSMTPD could specifically depend on it.
> >
> > The system would keep its default SSL library.
> >
> 
> Well, it's only my opinion so I can miss some points here. Briefly, why
> libressl doesn't come here:
>
> 1) The first problem is that unlike third-party "libasr" library these
> chaps "libressl" and "openssl" are way too close, and it creates
> temptations and mistakes. Due to human nature, new options provide more
> possibility to slip up. Being provided with two similar options, some
> developers won't be considering open-(libre-)ssl corner cases you've
> mentioned for example, some will mix these two solutions up, etc. All
> users, in general, hate the idea that due to these changes something can be
> randomly broken.
> 

This loses me, or I'm missing a keypoint:

To me, the fact that two libraries are close is not really a technical issue
that can't be overcome. Two different versions of OpenSSL could be installed
in different places, and this holds true for LibreSSL no ?

This seems more like a packaging issue because LibreSSL could very well stay
in /usr/lib/libressl, or whatever is the convention on the target distro, so
it lives side by side and doesn't affect other applications.

Say tomorrow I started OpenWhateverD, it relied solely on LibreSSL's libtls,
and you REALLY had an interest in it, how would you work that out ?


> It can be solved, but I don't know anybody from the Fedora community who'd
> be willing to:
> 
>   - reconcile issues on similar soname provides, naming, versioning etc.
> with Fedora and RedHat technical board in order to avoid all possible
> intersections with this critical system component;
>   - support "libressl" globally similar to "openssl" case, fixing security
> CVEs always getting in touch (being such package maintainer is not a
> one-time task);
>   - consult RH/Fedora developers promptly fixing their libressl-specific
> issues - and all this responsibility on a voluntary basis.
>

I can understand this but then it's a distribution specific issue and it isn't
limited by a technical problem. This can be taken into account when making the
move so that the package maintainer can sort things out but I don't think that
it should be a justification to prevent move and limit our progress.

If no one in the Fedora community would be willing to work out a solution then
it would be an indicator that we're holding back for a community that does not
really care so much about having the project or not. If that was the case then
it would question why we're holding back really :-)

If there is a technical problem, then it is different because we're willing to
help work things out.


> 2) From the enterprise point of view, there is no sense to support it as an
> openssl replacement now.
> It's not FIPS-certified so they cannot use it in enterprise solutions where
> openssl currently in charge. For simplicity, better not to have an unusable
> alternative (in context of this situation, of course). They won't sponsor
> its maintenance so it's up to the community. Surely this can change if
> business sees a use case for this specific library's clone but there is no
> any so far.
> 

Unlike the above, this is irrelevant to me, I don't think any opensource
project should be driven by what makes sense to a particular company.

We were sponsored full-time for over a year by my employer, and then the
direction we were taking no longer made sense for them.

We could have adapted our direction to keep the sponsoring, but it would
have been a bad thing for the project, so we part ways (on sponsorship).

Clearly, I can take anything into account but not this :-)


> The arguments on switching to libressl are quite logical, but I don't see a
> straight way how to do it in RHEL and Fedora considering all above.
> 

Ok, so then the question is:

There's no straight way, so how do we plan for a curvy way ? :-)


> By the way, how about GnuTLS support?
> 

We have no interest for that.

The code was written using the OpenSSL API because we were used to it
and clearly the push for a move to LibreSSL is primarily done because
it is a way out of the OpenSSL API and towards the libtls API.

Replacing an API that we don't like by another that doesn't bring any
clear improvements with 

Re: question to package maintainers

[Ryan Kavanagh]

On Thu, Dec 24, 2015 at 09:42:56AM +0100, Gilles Chehade wrote:
> > Out of curiosity, does anyone know how many people run OpenSMTP on
> > the offending systems compared to OpenBSD?

According to Debian popcon (an opt-in "popularity contest" for
packages), there are >= 19 people with opensmtpd installed on Debian.
https://qa.debian.org/popcon.php?package=opensmtpd

On Thu, Dec 24, 2015 at 07:17:12PM +0600, Denis Fateyev wrote:
> As an analogue, I can remember a mailing list thread in Debian where
> people were discussing Libressl packaging into Debian. They produced
> tens of messages but came to nothing at that point.

Indeed, Debian doesn't have libressl packaged yet, and as far as I know,
there's nobody actively working on packaging it either. Here's the
referenced discussion regarding getting it into Debian. There's been no
activity on it in a year an a half.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754513

Unfortunately, I don't have the time to take on packaging libressl
mysellf, nor do I want to take on the responsibility of maintaining it
long-term and dealing with any potential security vulnerabilities that
may arise in it, so it boils down to needing someone else to volunteer
to take care of it.

Happy holidays,
Ryan

-- 
|_)|_/  Ryan Kavanagh   | Debian Developer
| \| \  http://ryanak.ca/   | GPG Key 4A11C97A

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: question to package maintainers

[Tim Hume]

> On 24 Dec 2015, at 02:16, Gilles Chehade  wrote:
> 
>> On Wed, Dec 23, 2015 at 07:56:25PM +0600, Denis Fateyev wrote:
>>> On Wed, Dec 23, 2015 at 6:23 PM, Gilles Chehade  wrote:
>>> 
>>> 
>>> Would your distribution be affected if LibreSSL became a requirement ?
>>> 
>>> OpenSMTPD is starting to rely on LibreSSL-specific functions that will
>>> force us to go through painful hacks to maintain that dual SSL support
>>> and I'd like to know if switching to a LibreSSL-only mode is an option
>>> at this point or still too early.
>> 
>> 
>> It would be a problem in RHEL (and its derivatives like CentOS, Scientific,
>> Oracle, et al), and Fedora.
>> There were no plans of implementing Libressl support before, and there are
>> no plans to do it now.
> 
> I don't really get this, maybe there's a misunderstanding:
> 
> I understand that RHEL and others don't intend to switch to LibreSSL for
> their default SSL library and I'm not suggesting they should, this isn't
> our call, it's unreasonable to assume every system will switch and there
> is no debate about this.
> 
> What I'm wondering is if there's any reason that would prevent RHEL, for
> example, to package LibreSSL in the same way that libasr was packaged so
> that OpenSMTPD could specifically depend on it.
> 
> The system would keep its default SSL library.
> 
> 
>> As you might realize, linking Libressl statically is also not an option.
> 
> Yes, obviously I'm not advocating this ;-)
> 
> 
>> In my opinion, there is no point to forcibly depend on Libressl unless big
>> commercial players are interested in it.
> 
> Actually there are very strong rationales for this, I'll if you want but
> the bottom line:
> 
> - we're currently trying to support OpenSSL and LibreSSL as being the
>  same library and we're hitting corner cases that require us to hack
>  around detection, hack around compat and backport parts of LibreSSL
>  code in standalone files just so OpenSSL keeps working.
> 
> - we're facing cases of OpenSSL-induced #ifdefs because depending who
>  built it, it lacks AES_GCM, it lacks SNI, it lacks this and that. I
>  have broken SNI support at least once because of this.
> 
> - ultimately, we want to get rid of the OpenSSL historical interface
>  and rely on LibreSSL's libtls which will make TLS code readable. I
>  think we can all agree that it's scary that the most dangerous bit
>  of code in OpenSMTPD is also the less readable and the most error-
>  prone, we should take some steps towards changing this...
> 
> 
> 
> 
> -- 
> Gilles Chehade
> 
> https://www.poolp.org  @poolpOrg
> 
> -- 
> You received this mail because you are subscribed to misc@opensmtpd.org
> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
> 

--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: question to package maintainers

[Denis Fateyev]

On Dec 24, 2015 7:31 PM, "Gilles Chehade"  wrote:
> On Thu, Dec 24, 2015 at 07:17:12PM +0600, Denis Fateyev wrote:
> >
> > Well, you asked what distributions packagers thought, and I presented it
> > from point of the specific distribution. There are always some issues,
not
> > only pure technical ones.
> >
>
> I know and the reason I'm stating clearly my thoughts on this is so that
> you and others understand our position. I get it that you don't have all
> solutions at hands and that it might take time to solve them.

We currently have neither libressl requested nor specific policy for this
very case. Due to possible name collision and such we need to settle and
regulate lots of things, since something will definitely come out even
though the changes might look trivial.

> > I'll re-open libressl packaging discussion in Fedora right after
Christmas,
> > and in case of positive decision me or anybody else would support
libressl
> > pro bono. There is no schedule here.
> >
>
> Understood but that would already be a great step for us,
> Thanks

I'm personally not against of libressl as any other library, too.
But it always brings a lot of flame talks and concerns which packagers
naturally try to avoid. Let's see how it will go this time :-)

---
wbr, Denis.

Re: question to package maintainers

[Gilles Chehade]

On Wed, Dec 23, 2015 at 07:56:25PM +0600, Denis Fateyev wrote:
> On Wed, Dec 23, 2015 at 6:23 PM, Gilles Chehade  wrote:
> 
> >
> > Would your distribution be affected if LibreSSL became a requirement ?
> >
> > OpenSMTPD is starting to rely on LibreSSL-specific functions that will
> > force us to go through painful hacks to maintain that dual SSL support
> > and I'd like to know if switching to a LibreSSL-only mode is an option
> > at this point or still too early.
> 
> 
> It would be a problem in RHEL (and its derivatives like CentOS, Scientific,
> Oracle, et al), and Fedora.
> There were no plans of implementing Libressl support before, and there are
> no plans to do it now.
>

I don't really get this, maybe there's a misunderstanding:

I understand that RHEL and others don't intend to switch to LibreSSL for
their default SSL library and I'm not suggesting they should, this isn't
our call, it's unreasonable to assume every system will switch and there
is no debate about this.

What I'm wondering is if there's any reason that would prevent RHEL, for
example, to package LibreSSL in the same way that libasr was packaged so
that OpenSMTPD could specifically depend on it.

The system would keep its default SSL library.


> As you might realize, linking Libressl statically is also not an option.
>

Yes, obviously I'm not advocating this ;-)


> In my opinion, there is no point to forcibly depend on Libressl unless big
> commercial players are interested in it.
> 

Actually there are very strong rationales for this, I'll if you want but
the bottom line:

- we're currently trying to support OpenSSL and LibreSSL as being the
  same library and we're hitting corner cases that require us to hack
  around detection, hack around compat and backport parts of LibreSSL
  code in standalone files just so OpenSSL keeps working.

- we're facing cases of OpenSSL-induced #ifdefs because depending who
  built it, it lacks AES_GCM, it lacks SNI, it lacks this and that. I
  have broken SNI support at least once because of this.

- ultimately, we want to get rid of the OpenSSL historical interface
  and rely on LibreSSL's libtls which will make TLS code readable. I
  think we can all agree that it's scary that the most dangerous bit
  of code in OpenSMTPD is also the less readable and the most error-
  prone, we should take some steps towards changing this...




-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: question to package maintainers

[Gilles Chehade]

On Wed, Dec 23, 2015 at 07:56:02AM -0800, Richard wrote:
> On Wed, 23 Dec 2015, Gilles Chehade wrote:
> 
> > What I'm wondering is if there's any reason that would prevent RHEL, for
> > example, to package LibreSSL in the same way that libasr was packaged so
> > that OpenSMTPD could specifically depend on it.
> >
> > The system would keep its default SSL library.
> >
> 
> Library name collision
> --
> Libasr is a unique library name on Linux as far as I know and there is no
> problem installing it.
> 
> LibreSSL contains library names libcrypto and libssl which collide with
> the identical names in OpenSSL on most Linux systems.
>
> Can the libcrypto and libssl library names in LibreSSL be changed?
> 
> Maybe they can change to liblibrecrypto and liblibressl?
>
> LibreSSL also uses library libtls.
> Is libtls unique in Linux?
> 
> If not maybe it can change to liblibretls?
> 
> Changing the library names allows LibreSSL and OpenSSL to exist
> side by side on any Linux system.
> 

I'm well aware of that, but that's precisely what I'm suggesting:

If the ONLY reason keeping from depending on LibreSSL is that there is a
problem currently with the library name, then we can take a step back to
think of a solution that would solve this and help us move forward.


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: question to package maintainers

[Denis Fateyev]

On Wed, Dec 23, 2015 at 6:23 PM, Gilles Chehade  wrote:

>
> Would your distribution be affected if LibreSSL became a requirement ?
>
> OpenSMTPD is starting to rely on LibreSSL-specific functions that will
> force us to go through painful hacks to maintain that dual SSL support
> and I'd like to know if switching to a LibreSSL-only mode is an option
> at this point or still too early.


It would be a problem in RHEL (and its derivatives like CentOS, Scientific,
Oracle, et al), and Fedora.
There were no plans of implementing Libressl support before, and there are
no plans to do it now.

As you might realize, linking Libressl statically is also not an option.

In my opinion, there is no point to forcibly depend on Libressl unless big
commercial players are interested in it.

-- 
wbr, Denis.

Re: question to package maintainers

[Richard]

On Wed, 23 Dec 2015, Gilles Chehade wrote:

> What I'm wondering is if there's any reason that would prevent RHEL, for
> example, to package LibreSSL in the same way that libasr was packaged so
> that OpenSMTPD could specifically depend on it.
>
> The system would keep its default SSL library.
>

Library name collision
--
Libasr is a unique library name on Linux as far as I know and there is no
problem installing it.

LibreSSL contains library names libcrypto and libssl which collide with
the identical names in OpenSSL on most Linux systems.

Can the libcrypto and libssl library names in LibreSSL be changed?

Maybe they can change to liblibrecrypto and liblibressl?

LibreSSL also uses library libtls.
Is libtls unique in Linux?

If not maybe it can change to liblibretls?

Changing the library names allows LibreSSL and OpenSSL to exist
side by side on any Linux system.

Richard Narron

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: question to package maintainers

[Denis Fateyev]

On Wed, Dec 23, 2015 at 9:16 PM, Gilles Chehade  wrote:

>
> What I'm wondering is if there's any reason that would prevent RHEL, for
> example, to package LibreSSL in the same way that libasr was packaged so
> that OpenSMTPD could specifically depend on it.
>
> The system would keep its default SSL library.
>

Well, it's only my opinion so I can miss some points here. Briefly, why
libressl doesn't come here:

1) The first problem is that unlike third-party "libasr" library these
chaps "libressl" and "openssl" are way too close, and it creates
temptations and mistakes. Due to human nature, new options provide more
possibility to slip up. Being provided with two similar options, some
developers won't be considering open-(libre-)ssl corner cases you've
mentioned for example, some will mix these two solutions up, etc. All
users, in general, hate the idea that due to these changes something can be
randomly broken.

It can be solved, but I don't know anybody from the Fedora community who'd
be willing to:

  - reconcile issues on similar soname provides, naming, versioning etc.
with Fedora and RedHat technical board in order to avoid all possible
intersections with this critical system component;
  - support "libressl" globally similar to "openssl" case, fixing security
CVEs always getting in touch (being such package maintainer is not a
one-time task);
  - consult RH/Fedora developers promptly fixing their libressl-specific
issues - and all this responsibility on a voluntary basis.

2) From the enterprise point of view, there is no sense to support it as an
openssl replacement now.
It's not FIPS-certified so they cannot use it in enterprise solutions where
openssl currently in charge. For simplicity, better not to have an unusable
alternative (in context of this situation, of course). They won't sponsor
its maintenance so it's up to the community. Surely this can change if
business sees a use case for this specific library's clone but there is no
any so far.

The arguments on switching to libressl are quite logical, but I don't see a
straight way how to do it in RHEL and Fedora considering all above.

By the way, how about GnuTLS support?

-- 
wbr, Denis.

question to package maintainers

[Gilles Chehade]

Hi,

Would your distribution be affected if LibreSSL became a requirement ?

OpenSMTPD is starting to rely on LibreSSL-specific functions that will
force us to go through painful hacks to maintain that dual SSL support
and I'd like to know if switching to a LibreSSL-only mode is an option
at this point or still too early.

Gilles

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: Package maintainers

[Gilles Chehade]

There are going to be configure changes and I thought it would be nice to
centralize the things that will affect package managers so they don't have
to chase for information.

I can also do it on misc@, just proposing :-)
Le 11 oct. 2015 12:59 AM, "Denis Fateyev" <de...@fateyev.com> a écrit :

> On Fri, Oct 9, 2015 at 11:41 PM, Gilles Chehade <gil...@poolp.org> wrote:
>
>> EHLO package maintainers,
>>
>> It would be nice if we had a list and-or IRC channel to communicate with
>> you and synchronize before releases.
>>
>> Should I setup something ?
>>
>> --
>> Gilles Chehade
>>
>
>
> Well, as the OpenSMTPD RedHat/Fedora maintainer, I have neither severe
> functionality nor packaging issues nowadays like we had a year ago.
> Everything works pretty smoothly, that's why I've been keeping silent for
> a while ;-)
>
> Filling Github bugs on portable and discussing in the main list seem
> worked nice before due to low traffic. But if you feel that it would better
> to have a dedicated resource for packaging-specific topics, a new mailing
> list for this purpose would be a good idea.
>
> --
> wbr, Denis.
>

Re: Package maintainers

[Ashish SHUKLA]

On Fri, 9 Oct 2015 19:41:42 +0200, Gilles Chehade <gil...@poolp.org> said:
| EHLO package maintainers,

| It would be nice if we had a list and-or IRC channel to communicate with
| you and synchronize before releases.

| Should I setup something ?

Sure, although I think there was an IRC channel #opensmtpd-releases which
lasted for few releases, and you stopped hanging out there eventually ;)

Setting up a list for the purpose seems like a good/better idea.

Thanks!
-- 
Ashish SHUKLA

“He that teaches himself has a fool for a master.”
 (Benjamin Franklin)

Sent from my Emacs


signature.asc
Description: PGP signature

Package maintainers

[Gilles Chehade]

EHLO package maintainers,

It would be nice if we had a list and-or IRC channel to communicate with
you and synchronize before releases.

Should I setup something ?

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Heads-Up Package Maintainers

[Gilles Chehade]

Ohai,

For some reason, the tarball for 5.4.5p1 contained files used by the
autotools stuff which were more recent than source files, and caused
a bit of issues to some of you.

As some package maintainers have worked around the issue, I couldn't
just push a new fixed tarball with same version without taking risks
that it would break their work-around.

I have uploaded version 5.4.5p2 of OpenSMTPD today, it is not really
a new version, it is exactly the same code as 5.4.5p1 except that it
has the issue fixed.

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: RFC: package maintainers

[Ashish SHUKLA]

Hi,

On Sat, 26 Oct 2013 10:11:08 -0400, Ryan Kavanagh r...@debian.org said:

[...]


 2) Add an additional option specifying the subdirectory under which
opensmtpd-specific config files should go, say localconfdir, which
defaults to %(sysconfdir)/opensmtpd/:
a) Install aliases to %(sysconfdir)
b) Install all other config files to %(localconfdir).

I like this 2nd approach. ATM, FreeBSD port which I maintain patches OpenSMTPD
to use $PREFIX/etc/mail for its configuration. The reason would be to keep all
OpenSMTPD related configuration files (minus aliases) in one directory.

Thanks for bringing this, and like Ryan, I would also prefer to keep
downstream customizations/patches as less as possible.

Thanks
-- 
Ashish SHUKLA

“The Ministry of Peace concerns itself with war, the Ministry of Truth with
lies, the Ministry of Love with torture, and the Ministry of Plenty with
starvation.” (George Orwell, Nineteen Eighty-Four, 1949)

Sent from my Emacs


signature.asc
Description: PGP signature

Re: RFC: package maintainers

[Denis Fateyev]

Hi there,

On Sat, Oct 26, 2013 at 7:15 PM, Gilles Chehade gil...@poolp.org wrote:


 Upstream we do not really have a strong opinion and we'll do whatever
 makes it
 easier for most maintainers. This means that we're not opposed to adding
 brand
 new configure flags if it can help solving packaging issues, they just
 need to
 be discussed openly so there's a consensus and we don't see new ones
 appearing
 every few days :-)

 I don't know how other maintainers feel about this, they may have other
 issues
 with the current flags too, I can only encourage them to speak up.

 Oh, and we plan on a new stable release by mid-November, which leaves us
 about
 3 weeks to sort that out.


According all of that, if everybody except Fedora/RHEL use the same
directory for `smtpd.conf` and `aliases` and happy with it, better not to
do anything in upstream. I will write a tiny patch for Redhat system build.
If other maintainers change their opinion on that (Debian with putting
config into `/etc`, and Archlinux with shipping a dedicated aliases file),
it can be discussed again.

---
wbr, Denis.

Re: RFC: package maintainers

[Hugo Osvaldo Barrera]

On 2013-10-26 19:01, Denis Fateyev wrote:
 Hello there,
 
 On Sat, Oct 26, 2013 at 11:04 AM, Sébastien Luttringer se...@seblu.netwrote:
 
  Nothing wrong with this substitution. opensmtpd alias config file should
  be inside opensmtpd configuration directory.
 
 
 It shouldn't. At least, in Debian and Fedora.
 

What's the point of a dedicated directory for your mailers' config files,
if you're going to keep some files outside of it?

Also, why would you NEED to have an existing aliases file and share
it between mailers? Is it common to have many mailers using the same
aliases file?

If you REALLY need to keep a pre-existing aliases (foreign to you
package), can you just symlink /etc/opensmtpd/aliases - /etc/aliases ?

 
  In archlinux, postfix uses /etc/postfix/aliases, exim use
  /etc/mail/aliases. If you want an aliases file in /etc, all the code
  handling this will (creation, conflict between package, path fixes)
  should be in your distribution, not in the upstream package.
 
 
 I have no idea what specific they do in Archlinux, but in Debian and
 Fedora/RHEL there are neither symlinks nor dedicated `aliases` by each mail
 server. From Debian postfix default configuration (`/etc/postfix/main.cf`):
 --
 alias_maps = hash:/etc/aliases
 alias_database = hash:/etc/aliases
 --
 From Debian exim default configuration file:
 ---
 # This router handles aliasing using a traditional /etc/aliases file.
 #
 # NB  You must ensure that /etc/aliases exists. It used to be the case
 # NB  that every Unix had that file, because it was the Sendmail
 default.
 # NB  These days, there are systems that don't have it. Your aliases
 # NB  file should at least contain an alias for postmaster.
 ...
 system_aliases:
   debug_print = R: system_aliases for $local_part@$domain
   driver = redirect
   domains = +local_domains
   allow_fail
   allow_defer
   data = ${lookup{$local_part}lsearch{/etc/aliases}}
 ...
 ---
 The same in Fedora and RHEL, I don't even need to check its behavior.
 
 
 If I put my opensmtpd configuration in /config/opensmtpd, I don't expect
  ./configure try to write something in /etc!
 
 
 Right now Debian package uses `/etc/smtpd.conf` (
 http://packages.debian.org/en/sid/amd64/opensmtpd/filelist )
 They don't have the problem we are discussing because they have everything
 in `/etc`. If they decide to change configuration directory, they face the
 same issue.
 
 
 
  If you have kind of legacy to handle, maybe a symlink can help you.
 
 
 I would be a little patch that fixes substitution there where it isn't
 needed.
 
 ---
 wbr, Denis.

-- 
Hugo Osvaldo Barrera


pgp6GlQEJv07f.pgp
Description: PGP signature

Re: RFC: package maintainers

[Sébastien Luttringer]

On 26/10/2013 00:48, Denis Fateyev wrote:
 Hi there,
 
 To describe this issue in some details: we have a problem on portable
 when trying to place smtpd.conf not into `%{sysconfdir}` which is
 usually `/etc`, but into another directory (`/etc/opensmtpd`, for example.)
 
 Reason: opensmtpd always puts smtpd.conf into `%{sysconfdir}`, and the
 only way now to use another directory is to re-assign `%{sysconfdir}` in
 `./configure`. This is definitely not a good idea since `%{sysconfdir}`
 can be used for other purposes during build. Incorrect `%{sysconfdir}`

Is opensmtpd plan to have more than one place for its config? I guess no.

So why not keep sysconfdir and set a default value to /etc/smtpd
(default pool is /var/spool/smtpd) instead of using a non standard new
value?

Most packager expect this behavior.

$ grep -ri sysconfdir=/etc/ /var/abs |egrep
(light|xorg|openssh|openldap|squid|quagga|pdns)
/var/abs/community/pdns/PKGBUILD:--sysconfdir=/etc/powerdns \
/var/abs/community/quagga/PKGBUILD:--sysconfdir=/etc/quagga \
/var/abs/community/squid/PKGBUILD:--sysconfdir=/etc/squid \
/var/abs/core/openldap/PKGBUILD:  make prefix=/usr libexecdir=/usr/lib
sysconfdir=/etc/openldap
/var/abs/core/openssh/PKGBUILD: --sysconfdir=/etc/ssh \
/var/abs/extra/lighttpd/PKGBUILD:   --sysconfdir=/etc/lighttpd \
/var/abs/extra/xorg-server/PKGBUILD:  --sysconfdir=/etc/X11 \

Cheers,

-- 
Sébastien Seblu Luttringer
https://www.seblu.net
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

Re: RFC: package maintainers

[Denis Fateyev]

On Sat, Oct 26, 2013 at 5:21 AM, Sébastien Luttringer se...@seblu.netwrote:


 So why not keep sysconfdir and set a default value to /etc/smtpd
 (default pool is /var/spool/smtpd) instead of using a non standard new
 value?


The default value should be then `/etc/opensmtpd` since we agreed during
the last conversation with Charles, that package should be called
opensmtpd in portable. And as mentioned before, we definitely shouldn't
touch %{sysconfdir} for such things like setting smtpd.conf location.

Hardcoded `%{sysconfdir}/opensmtpd` for config path is better than the
current situation. I think it should be ok.

---
wbr, Denis.



 Most packager expect this behavior.

 $ grep -ri sysconfdir=/etc/ /var/abs |egrep
 (light|xorg|openssh|openldap|squid|quagga|pdns)
 /var/abs/community/pdns/PKGBUILD:--sysconfdir=/etc/powerdns \
 /var/abs/community/quagga/PKGBUILD:--sysconfdir=/etc/quagga \
 /var/abs/community/squid/PKGBUILD:--sysconfdir=/etc/squid \
 /var/abs/core/openldap/PKGBUILD:  make prefix=/usr libexecdir=/usr/lib
 sysconfdir=/etc/openldap
 /var/abs/core/openssh/PKGBUILD: --sysconfdir=/etc/ssh \
 /var/abs/extra/lighttpd/PKGBUILD:   --sysconfdir=/etc/lighttpd
 \
 /var/abs/extra/xorg-server/PKGBUILD:  --sysconfdir=/etc/X11 \

 Cheers,

 --
 Sébastien Seblu Luttringer
 https://www.seblu.net
 GPG: 0x2072D77A

Re: RFC: package maintainers

[Sébastien Luttringer]

On 26/10/2013 01:37, Denis Fateyev wrote:
 The default value should be then `/etc/opensmtpd` since we agreed during
 the last conversation with Charles, that package should be called
 opensmtpd in portable.
While the name is the same in /var/spool and /etc by default and I can
override the both it's perfect.

 And as mentioned before, we definitely
 shouldn't touch %{sysconfdir} for such things like setting
 smtpd.conf location.

- And it's the source of the problem...
- This is definitely not a good idea since...
- we definitely shouldn't touch...

I disagree. It's the purpose of this variable! sysconfdir is the path to
your package configuration directory after installation. Not a kind of
global system one! It's not the path to directory containing the passwd
file. It's the path where you expect to have your files after a
_classic_ make install.[1]

For what other reasons do you want to use this variable?

[1] http://www.gnu.org/prep/standards/html_node/Directory-Variables.html


-- 
Sébastien Seblu Luttringer
https://www.seblu.net
GPG: 0x2072D77A



signature.asc
Description: OpenPGP digital signature

Re: RFC: package maintainers

[Denis Fateyev]

On Sat, Oct 26, 2013 at 6:43 AM, Sébastien Luttringer se...@seblu.netwrote:


 - And it's the source of the problem...
 - This is definitely not a good idea since...
 - we definitely shouldn't touch...

 I disagree. It's the purpose of this variable! sysconfdir is the path to
 your package configuration directory after installation. Not a kind of
 global system one! It's not the path to directory containing the passwd
 file. It's the path where you expect to have your files after a
 _classic_ make install.[1]


Got it, now I understand what you're talking about. You can name it
`package configuration directory` or `global system one`, because now they
are the same in the package configure logic. They should be divided in some
way, that's my point. The fact is: now smtpd.conf contains wrong
substitution for `/etc/aliases` because it assumes that the same directory.
We put `/etc/opensmtpd` in %{sysconfdir} - we got `/etc/opensmtpd/aliases`
in the default config which is wrong.

---
wbr, Denis.