Re: procmail question

2024-01-26 Thread Wolfgang Pfeiffer via users 

On Fri, Jan 26, 2024 at 09:08:44AM -0600, Thomas Cameron wrote:

I'm reading articles saying procmail is dangerous and unmaintained
(https://anarc.at/blog/2022-03-02-procmail-considered-harmful/).


Quote from the page above - seems to be old and, to put it mildly,
wrong:
"procmail is unmaintained. The "Final release", according to
Wikipedia, dates back to September 10, 2001 (3.22)"

Status today according to
https://en.wikipedia.org/wiki/Procmail
Excerpt:
"The software remained unmaintained for several years, and was
believed to be defunct.[3] In 2020 May, Stephen van den Berg resumed
maintenance again.[4] The program has since seen multiple releases and
bug-fixes."

Here seems to be the current maintainer site:
https://github.com/BuGlessRB/procmail
And see the HISTORY file in that dir ...

And even the Openbsd guys, with their interest in "proactive
security", have it in their latest release:
https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/

Welcome! ... ;)
--
Wolfgang
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: procmail question

2024-01-26 Thread Robert Nichols 

On 1/26/24 14:39, Samuel Sieb wrote:

On 1/26/24 09:07, Jon Ingason via users wrote:

Did following:

$ dnf search procmail
Fedora 39 - x86_64  9.3 MB/s |  89 MB


= Namn Exakt matchad: procmail
procmail.x86_64 : Mail processing program
=== Namn & Sammanfattning Matchad: procmail
perl-Mail-Procmail.noarch : Procmail-like facility for creating easy mail
   : filters

So procmail indeed is still maintained.


That just means it's still being packaged by someone for Fedora.  That doesn't 
provide any information about whether the program's source code is being 
maintained upstream.


Indeed, the upstream source at https://github.com/BuGlessRB/procmail has not 
seen any activity for the last 2 years.

I guess I had better hang onto that source. My email gets some fairly messy 
processing that is very dependent on procmail.

--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.

--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: 389 DS 2.3.6 on RHEL 9 replication over TLS

2024-01-26 Thread Marc Sauton 
"LDAP error: Can't contact LDAP server (connection error)" is kind of
generic, but often relates to PKI trust misconfiguration when TLS is used,
a common issue is the issuer / CA certificate(s) chain is not installed, or
not trusted.
There should be a message in the access log, for example "Peer does not
recognize and trust the CA that issued your certificate."

a typical scenario is when the default test /demo/self signed certs are
left over and used between 2 LDAP instances for replication, we have an
example in this article (subscription required)
  https://access.redhat.com/solutions/6449561
  How To test LDAPS with RHDS instances on 2 systems and default test CA
this happens as there is no shared configuration between instances.

in the links Thierry B. posted, also see this chapter:

1.8. Adding the CA certificate used by Directory Server to the trust store
of Red Hat Enterprise Linux
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds#proc_adding-the-ca-certificate-used-by-directory-server-to-the-trust-store-of-red-hat-enterprise-linux_assembly_enabling-tls-encrypted-connections-to-directory-server

I usually run a "trust anchor some.file.ca.crt" command, and add the
issuer(s) to the LDAP instance's NSS db.



On Fri, Jan 26, 2024 at 1:21 AM Thierry Bordaz  wrote:

> You may follow the doc to configure TLS on your both suppliers [1] and
> check the trusted CA on both side [2]. On troubleshooting side you may look
> at [3]
>
> [1]
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds#doc-wrapper
> [2]
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_changing-the-ca-trust-flagssecuring-rhds#doc-wrapper
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/configuring_and_managing_replication/assembly_troubleshooting-replication-related-problems_configuring-and-managing-replication
>
>
> On 1/25/24 23:55, Ciara Gadsden wrote:
>
> Idk how to do that lol
>
> Sent from my Boost Samsung Galaxy A23 5G
> Get Outlook for Android 
> --
> *From:* Simon Pichugin  
> *Sent:* Thursday, January 25, 2024 5:44:57 PM
> *To:* General discussion list for the 389 Directory server project.
> <389-users@lists.fedoraproject.org> <389-users@lists.fedoraproject.org>
> *Cc:* alexander_nazare...@harvard.edu 
> 
> *Subject:* [389-users] Re: 389 DS 2.3.6 on RHEL 9 replication over TLS
>
> Hello Alex,
> I think we need a bit more information here.
>
> First of all, could you please run the "dsconf repl-agmt create" (LDAPS
> one) with "-v" flag? It will give a detailed verbose output.
> Also, I recommend checking the server's error and access log for more
> information why it fails (additionally, you may enable at least 16384+8192
> (Default + Replication debugging) in nsslapd-errorlog-level).
>
> As for possible issues and actions, at first glance, I recommend checking
> that the TLS certificates used are correctly installed and trusted on both
> the supplier and consumer instances. It's important that the instances
> trust each other; even though ldapsearch (OpenLDAP client) on the supplier
> already trusts the consumer machine, it's not enough.
>
> Sincerely,
> Simon
>
>
>
> On Thu, Jan 25, 2024 at 1:07 PM Nazarenko, Alexander <
> alexander_nazare...@harvard.edu> wrote:
>
> Hello colleagues,
>
>
>
> Lately we started looking into 389 DS 2.3.6 on RHEL 9 platform.
>
>
>
> We followed instructions Configuring and managing replication
> 
> on Red Hat site to establish replication between two remote instances,
>
> The instances where previously configured to support TLS channel on port
> 636 (Enabling TLS-encrypted connections to Directory Server
> 
> ) , and we made sure ldapsearch is working with LDAPS:// protocol with
> the certificate verification (TLS_REQCERT demand).
>
>
>
> The following issue with the replication over TLS was observed:
>
>
>
> After we ran the command below to configure secure replication:
>
> dsconf -D "cn=Directory Manager"  -w *** ldaps://server.example.edu
> repl-agmt create --suffix "dc=example,dc=com" --host "consumer.example.edu"
> --port 636 --conn-protocol=LDAPS --bind-dn "cn=replication
> manager,cn=config" --bind-passwd "***" --bind-method=SIMPLE --init
> consumer.example.edu-RO
>
>
>
> the error occurred:
>
> Error (-1) Problem connecting to replica -

Re: procmail question

2024-01-26 Thread Samuel Sieb 

On 1/26/24 09:07, Jon Ingason via users wrote:

Did following:

$ dnf search procmail
Fedora 39 - x86_64  9.3 MB/s |  89 MB


= Namn Exakt matchad: procmail
procmail.x86_64 : Mail processing program
=== Namn & Sammanfattning Matchad: procmail
perl-Mail-Procmail.noarch : Procmail-like facility for creating easy mail
   : filters

So procmail indeed is still maintained.


That just means it's still being packaged by someone for Fedora.  That 
doesn't provide any information about whether the program's source code 
is being maintained upstream.

--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: procmail question

2024-01-26 Thread Jon Ingason via users 

Den 2024-01-26 kl. 17:26, skrev Thomas Cameron:

On 1/26/24 10:10, Patrick O'Callaghan wrote:

I used procmail for years and never had an issue with it. However I
don't like unmaintained software so removed it when support was
dropped. The problem with Sieve (and several other options) is that
they're server-side, so if your server doesn't support them, and you
don't want to run your own local server (plus e.g. fetchmail) you're
dependent on what your mail provider allows.


I run the servers, so I can install whatever I want, but... I chatted 
with a couple of folks on IRC, including someone who knows the guy who 
wrote that article. Turns out that procmail really IS still being 
maintained, both by vendors like Red Hat, Canonical, Suse, etc., and 
independent developers. There's even talk about forming a new mailing 
list for those developers. It's definitely being maintained.


After digging in a bit, I'm going to stick with procmail since I already 
know it.


If anyone has any opinions to the contrary, I'm happy to be educated, 
though!




Did following:

$ dnf search procmail
Fedora 39 - x86_64  9.3 MB/s |  89 MB


= Namn Exakt matchad: procmail
procmail.x86_64 : Mail processing program
=== Namn & Sammanfattning Matchad: procmail
perl-Mail-Procmail.noarch : Procmail-like facility for creating easy mail
  : filters

So procmail indeed is still maintained.

--
Regards

Jon Ingason


--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: procmail question

2024-01-26 Thread Thomas Cameron 

On 1/26/24 10:10, Patrick O'Callaghan wrote:

I used procmail for years and never had an issue with it. However I
don't like unmaintained software so removed it when support was
dropped. The problem with Sieve (and several other options) is that
they're server-side, so if your server doesn't support them, and you
don't want to run your own local server (plus e.g. fetchmail) you're
dependent on what your mail provider allows.


I run the servers, so I can install whatever I want, but... I chatted 
with a couple of folks on IRC, including someone who knows the guy who 
wrote that article. Turns out that procmail really IS still being 
maintained, both by vendors like Red Hat, Canonical, Suse, etc., and 
independent developers. There's even talk about forming a new mailing 
list for those developers. It's definitely being maintained.


After digging in a bit, I'm going to stick with procmail since I already 
know it.


If anyone has any opinions to the contrary, I'm happy to be educated, 
though!


--
Thanks!
Thomas
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: procmail question

2024-01-26 Thread Patrick O'Callaghan 
On Fri, 2024-01-26 at 09:08 -0600, Thomas Cameron wrote:
> I'm reading articles saying procmail is dangerous and unmaintained 
> (https://anarc.at/blog/2022-03-02-procmail-considered-harmful/).
> 
> I get why a setuid root:mail binary is potentially dangerous, but 
> procmail has been in use for decades and I don't think I've ever
> heard 
> of it being used for an exploit except for way back in 2017 and
> 2014 
> (
> https://www.cvedetails.com/vulnerability-list/vendor_id-225/Procmail.h
> tml). 
> 
> 
> Anyone got any recommendations? I've used procmail for decades. I'm 
> pretty familiar with it. I *can* migrate to sieve, but procmail Just 
> Works(TM), so I'm hesitant.
> 
> Is the risk overblown? We're using Postfix and procmail and it seems
> to 
> be really solid. I am not really looking forward to migrating to
> sieve, 
> so I'd rather just stick with what I know, you know?
> 
> What are your thoughts?

I used procmail for years and never had an issue with it. However I
don't like unmaintained software so removed it when support was
dropped. The problem with Sieve (and several other options) is that
they're server-side, so if your server doesn't support them, and you
don't want to run your own local server (plus e.g. fetchmail) you're
dependent on what your mail provider allows.

poc
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

procmail question

2024-01-26 Thread Thomas Cameron 
I'm reading articles saying procmail is dangerous and unmaintained 
(https://anarc.at/blog/2022-03-02-procmail-considered-harmful/).


I get why a setuid root:mail binary is potentially dangerous, but 
procmail has been in use for decades and I don't think I've ever heard 
of it being used for an exploit except for way back in 2017 and 2014 
(https://www.cvedetails.com/vulnerability-list/vendor_id-225/Procmail.html). 



Anyone got any recommendations? I've used procmail for decades. I'm 
pretty familiar with it. I *can* migrate to sieve, but procmail Just 
Works(TM), so I'm hesitant.


Is the risk overblown? We're using Postfix and procmail and it seems to 
be really solid. I am not really looking forward to migrating to sieve, 
so I'd rather just stick with what I know, you know?


What are your thoughts?

--
Thomas
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: 389 DS 2.3.6 on RHEL 9 replication over TLS

2024-01-26 Thread Thierry Bordaz 
You may follow the doc to configure TLS on your both suppliers [1] and 
check the trusted CA on both side [2]. On troubleshooting side you may 
look at [3]


[1] 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds#doc-wrapper
[2] 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_changing-the-ca-trust-flagssecuring-rhds#doc-wrapper
[3] 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/configuring_and_managing_replication/assembly_troubleshooting-replication-related-problems_configuring-and-managing-replication



On 1/25/24 23:55, Ciara Gadsden wrote:

Idk how to do that lol

Sent from my Boost Samsung Galaxy A23 5G
Get Outlook for Android 

*From:* Simon Pichugin 
*Sent:* Thursday, January 25, 2024 5:44:57 PM
*To:* General discussion list for the 389 Directory server project. 
<389-users@lists.fedoraproject.org>

*Cc:* alexander_nazare...@harvard.edu 
*Subject:* [389-users] Re: 389 DS 2.3.6 on RHEL 9 replication over TLS
Hello Alex,
I think we need a bit more information here.

First of all, could you please run the "dsconf repl-agmt create" 
(LDAPS one) with "-v" flag? It will give a detailed verbose output.
Also, I recommend checking the server's error and access log for more 
information why it fails (additionally, you may enable at least 
16384+8192 (Default + Replication debugging) in nsslapd-errorlog-level).


As for possible issues and actions, at first glance, I recommend 
checking that the TLS certificates used are correctly installed and 
trusted on both the supplier and consumer instances. It's important 
that the instances trust each other; even though ldapsearch (OpenLDAP 
client) on the supplier already trusts the consumer machine, it's not 
enough.


Sincerely,
Simon



On Thu, Jan 25, 2024 at 1:07 PM Nazarenko, Alexander 
 wrote:


Hello colleagues,

Lately we started looking into 389 DS 2.3.6 on RHEL 9 platform.

We followed instructions Configuring and managing replication


on Red Hat site to establish replication between two remote instances,

The instances where previously configured to support TLS channel
on port 636 (Enabling TLS-encrypted connections to Directory
Server

),
and we made sure ldapsearch is working with LDAPS:// protocol with
the certificate verification (TLS_REQCERT demand).

The following issue with the replication over TLS was observed:

After we ran the command below to configure secure replication:

dsconf -D "cn=Directory Manager"  -w ***
ldaps://server.example.edu  repl-agmt
create --suffix "dc=example,dc=com" --host "consumer.example.edu
" --port 636 --conn-protocol=LDAPS
--bind-dn "cn=replication manager,cn=config" --bind-passwd "***"
--bind-method=SIMPLE --init consumer.example.edu-RO

the error occurred:

Error (-1) Problem connecting to replica - LDAP error: Can't
contact LDAP server (connection error)

We double-checked that after we configure clear text replication
with the command:

dsconf -D "cn=Directory Manager"  -w ***
ldaps://server.example.edu  repl-agmt
create --suffix "dc=example,dc=com" --host "consumer.example.edu
" --port 389 --conn-protocol=LDAP
--bind-dn "cn=replication manager,cn=config" --bind-passwd "***"
--bind-method=SIMPLE --init 10.140.133.36-RO

no problem occurred, and the replication completed successfully.

My question is whether this means the replication over TLS
required different config steps, and if yes – what they are?

Thank you,

- Alex

--
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue


--
___
389-users mailing list --389-users@lists.fedoraproject.org
To unsubscribe