> Do you have a permissions issue? Directories owned by root but trying to write as www user?

spoolnews/bbsmail/* all owned by www user, no root ownership

i'm going to spend the rest of the morning debugging mail.php->send_external_mail() and seeing where the failure is.

--
Posted on Rocksolid Light

Found it.

Here was the problem:
include "../common/config.inc.php";

from config.inc.php:
$config_name = basename(getcwd());

in mail.php, $config_name is used to build the $outgoing_dir path.
on my system, since the user is accessing www/spoolnews/mail.php, $config_name works out to "spoolnews"

after the path is built, $outgoing_dir becomes: /www/common/../../spoolnews/spoolnews/outgoing --> this is not a real directory

the path is supposed to be www/common../../spoolnews/tomonet/outgoing

so I'm going to have to rethink of how $config_name is set in config.inc.php. The basename(getcwd()) works in most situations, except when the user is accessing scripts in www/tomonet/spoolnews/

--
Posted on Rocksolid Light

COOL! I did a quick kludge as a workaround - I moved mail.php to /www/tomonet/
Let me know if you think that this will have any deleterious long-term effects with RSL - fwiw, I think it's a non-issue.

i'm now getting @@RSL BBSMAIL notice posted in tomonet.shared.test
The message is empty after Organization:, so that's telling me gnupg isn't encrypting anything. But this is progress! I'm guessing it's just a gnupg configuration issue to figure out now.

--
Posted on Rocksolid Light

vga256 wrote:

> COOL! I did a quick kludge as a workaround - I moved mail.php to /www/tomonet/
> Let me know if you think that this will have any deleterious long-term effects with RSL - fwiw, I think it's a non-issue.

Nice! I also think it's a non-issue. I put it where I did so $config_name would always be spoolnews, but it's not critical and should work. I haven't tried it elsewhere, but I think it's ok.

> i'm now getting @@RSL BBSMAIL notice posted in tomonet.shared.test
> The message is empty after Organization:, so that's telling me gnupg isn't encrypting anything. But this is progress! I'm guessing it's just a gnupg configuration issue to figure out now.

That sounds correct.

Organization is the last line of the header, so there is no body at all. The body should contain a PGP encrypted message. This is all in semd_external_mail.

I'm guessing that you do not have the KEY for the target domain. I've fixed this in the newer interBBS_mail.php I posted about this morning, but your copy would silently fail.

You can check keys from the command line:

export GNUPGHOME=<whatever you set it to in gpg.conf>
gpg --list-keys

--
Retro Guy

Retro Guy wrote:

> vga256 wrote:

>> COOL! I did a quick kludge as a workaround - I moved mail.php to /www/tomonet/
>> Let me know if you think that this will have any deleterious long-term effects with RSL - fwiw, I think it's a non-issue.

> Nice! I also think it's a non-issue. I put it where I did so $config_name would always be spoolnews, but it's not critical and should work. I haven't tried it elsewhere, but I think it's ok.

>> i'm now getting @@RSL BBSMAIL notice posted in tomonet.shared.test
>> The message is empty after Organization:, so that's telling me gnupg isn't encrypting anything. But this is progress! I'm guessing it's just a gnupg configuration issue to figure out now.

> That sounds correct.

> Organization is the last line of the header, so there is no body at all. The body should contain a PGP encrypted message. This is all in semd_external_mail.

> I'm guessing that you do not have the KEY for the target domain. I've fixed this in the newer interBBS_mail.php I posted about this morning, but your copy would silently fail.

> You can check keys from the command line:

> export GNUPGHOME=<whatever you set it to in gpg.conf>
> gpg --list-keys

'gpg --list-secret-keys' should list your own key.

These all need to be run as the www user.

Also, the domain you send to 'sysop@some.domain' must match the key. So, 'some.domain' must be the domain that the key contains. When you try to retrieve a key, if you try from rslight to auto-retrieve it and the domain you point to to get it does not match the domain inside the key, it will fail (rslight will immediately delete the key for security reasons).

Your value for domain in gpg.conf must match exactly the domain you try to send to, and rslight must be able to contact that domain and find <domain>/pubkey/server_pubkey.txt if you wish to have it automatically retrieve a key.

You can also retrieve keys manually if necessary. You would get a copy of the domain's 'server_pubkey.txt' and save it.

Then 'gpg --import the.filename.containing.the.key'

Just tossing more info out there.

--
Retro Guy

Retro Guy wrote:

> Your value for domain in gpg.conf must match exactly the domain you try to send to, and rslight must be able to contact that domain and find <domain>/pubkey/server_pubkey.txt if you wish to have it automatically retrieve a key.

The above is misleading (incorrect). It should say:

Your value for domain in gpg.conf must match exactly the domain that others use to try to send to you, and must match exactly the domain they would use to try to access your server_pubkey.txt file.

Don't know what I was thinking there, lol.

--
Retro Guy

Okay, so I've got .gnupg with permissions 0700, owned by www user, and in a folder accessible by www user.

Still getting the exact same errors as before: "get_key failed" when trying to gnupg_addsignkey() and gnupg_adddecryptkey() in mail.php

$res is being set as resource(33) of type (ctx), so *something* is happening. unfortunately gpg's error output is nearly useless for debugging environment issues.

i'm calling it quits here, I think. 7 hours trying to get GPG working hasn't been fun.

--
Posted on Rocksolid Light

vga256 wrote:

> Okay, so I've got .gnupg with permissions 0700, owned by www user, and in a folder accessible by www user.

> Still getting the exact same errors as before: "get_key failed" when trying to gnupg_addsignkey() and gnupg_adddecryptkey() in mail.php

> $res is being set as resource(33) of type (ctx), so *something* is happening. unfortunately gpg's error output is nearly useless for debugging environment issues.

Please verify that you have a private key, also, to see if you get errors from command line gpg:

gpg --list-secret-keys (make sure you set GNUPGHOME first)

If you do not have a secret key, then it's not being created by create_gpg_keys.sh.

If you do have a secret key, then the problem is different.

--
Retro Guy

Retro Guy wrote:
> Please verify that you have a private key, also, to see if you get errors from command line gpg:
> gpg --list-secret-keys (make sure you set GNUPGHOME first)
> If you do not have a secret key, then it's not being created by create_gpg_keys.sh.
> If you do have a secret key, then the problem is different.

I should have clarified earlier - no errors from gpg, gnupghome is set correctly, and I have both private and public keys stored for [ultimate] tomo@tomo.dialup.cafe

--
Posted on Rocksolid Light

mercifully, i've discovered
gnupg_getengineinfo($res) - which shows:
Array ( [protocol] => 6 [file_name] => /nonexistent [home_dir] => )

so, obviously something super screwy going on here, despite
putenv("GNUPGHOME=".$rslight_gpg['gnupghome']) being correctly set earlier.

--
Posted on Rocksolid Light

vga256 wrote:

> Retro Guy wrote:
>> Please verify that you have a private key, also, to see if you get errors from command line gpg:
>> gpg --list-secret-keys (make sure you set GNUPGHOME first)
>> If you do not have a secret key, then it's not being created by create_gpg_keys.sh.
>> If you do have a secret key, then the problem is different.

> I should have clarified earlier - no errors from gpg, gnupghome is set correctly, and I have both private and public keys stored for [ultimate] tomo@tomo.dialup.cafe

This kind of stuff irritates all of us when trying to work stuff out. I spend hours and hours only to find some simple thing (hopefully)

Do you have the file, $keydir.'/server_fingerprint.txt' ?

It should look something like:

1ADF EF1C E1A0 4BC9 0F78 9EBD EEE7 B9EF E668 0B96

That is sourced, then all spaces are removed, then the result is sent as '$fingerprint_clean' to:
gnupg_addsignkey($res,$fingerprint_clean);
gnupg_adddecryptkey($res,$fingerprint_clean, '');

If all that is good, I would then add logging for those functions to display which one fails. Maybe also printing $fingerprint_clean in the log.

If $res is good, and $fingerprint_clean is good, then something stupid is causing the failure.

Then we write a test script to just try to write an encrypted file. A script you can run manually and watch for errors.

--
Retro Guy

vga256 wrote:

> mercifully, i've discovered
> gnupg_getengineinfo($res) - which shows:
> Array ( [protocol] => 6 [file_name] => /nonexistent [home_dir] => )

> so, obviously something super screwy going on here, despite
> putenv("GNUPGHOME=".$rslight_gpg['gnupghome']) being correctly set earlier.

Interesting. I know you already know to try most of the suggestions, but just in case. Maybe try displying 'getenv("GNUPGHOME");' right before setting $res.

--
Retro Guy

Retro Guy wrote:> Do you have the file, $keydir.'/server_fingerprint.txt' ?

> It should look something like:

> 1ADF EF1C E1A0 4BC9 0F78 9EBD EEE7 B9EF E668 0B96

> That is sourced, then all spaces are removed, then the result is sent as '$fingerprint_clean' to:

> gnupg_addsignkey($res,$fingerprint_clean);
> gnupg_adddecryptkey($res,$fingerprint_clean, '');

> If all that is good, I would then add logging for those functions to display which one fails. Maybe also printing $fingerprint_clean in the log.

yep, all of the above done and already checked out hours ago.

> If $res is good, and $fingerprint_clean is good, then something stupid is causing the failure.

> Then we write a test script to just try to write an encrypted file. A script you can run manually and watch for errors.

my most recent post shows that gnupg_init() is producing a resource that cannot function properly, because file_name (the location of gpg2) and home_dir (the location of the .gnupg files) are not being set properly.

I even went so far as to manually force the locations:
$res = gnupg_init(["file_name" => "/opt/local/bin/gpg", "home_dir" => $rslight_gpg['gnupghome']]);

and it still does not yield a useful resource:
Array ( [protocol] => 6 [file_name] => /nonexistent [home_dir] => )

--
Posted on Rocksolid Light

vga256 wrote:

> Retro Guy wrote:> Do you have the file, $keydir.'/server_fingerprint.txt' ?

>> It should look something like:

>> 1ADF EF1C E1A0 4BC9 0F78 9EBD EEE7 B9EF E668 0B96

>> That is sourced, then all spaces are removed, then the result is sent as '$fingerprint_clean' to:

>> gnupg_addsignkey($res,$fingerprint_clean);
>> gnupg_adddecryptkey($res,$fingerprint_clean, '');

>> If all that is good, I would then add logging for those functions to display which one fails. Maybe also printing $fingerprint_clean in the log.

> yep, all of the above done and already checked out hours ago.

>> If $res is good, and $fingerprint_clean is good, then something stupid is causing the failure.

>> Then we write a test script to just try to write an encrypted file. A script you can run manually and watch for errors.

> my most recent post shows that gnupg_init() is producing a resource that cannot function properly, because file_name (the location of gpg2) and home_dir (the location of the .gnupg files) are not being set properly.

> I even went so far as to manually force the locations:
> $res = gnupg_init(["file_name" => "/opt/local/bin/gpg", "home_dir" => $rslight_gpg['gnupghome']]);

Do I see TWO trailing brackets above? ']]);' Maybe just a typo, but maybe in the file.

--
Retro Guy

Retro Guy wrote:

> vga256 wrote:

>> Retro Guy wrote:> Do you have the file, $keydir.'/server_fingerprint.txt' ?

>>> It should look something like:

>>> 1ADF EF1C E1A0 4BC9 0F78 9EBD EEE7 B9EF E668 0B96

>>> That is sourced, then all spaces are removed, then the result is sent as '$fingerprint_clean' to:

>>> gnupg_addsignkey($res,$fingerprint_clean);
>>> gnupg_adddecryptkey($res,$fingerprint_clean, '');

>>> If all that is good, I would then add logging for those functions to display which one fails. Maybe also printing $fingerprint_clean in the log.

>> yep, all of the above done and already checked out hours ago.

>>> If $res is good, and $fingerprint_clean is good, then something stupid is causing the failure.

>>> Then we write a test script to just try to write an encrypted file. A script you can run manually and watch for errors.

>> my most recent post shows that gnupg_init() is producing a resource that cannot function properly, because file_name (the location of gpg2) and home_dir (the location of the .gnupg files) are not being set properly.

>> I even went so far as to manually force the locations:
>> $res = gnupg_init(["file_name" => "/opt/local/bin/gpg", "home_dir" => $rslight_gpg['gnupghome']]);

> Do I see TWO trailing brackets above? ']]);' Maybe just a typo, but maybe in the file.

Oh, I should go do something else for a while. It should have TWO brackets :(

--
Retro Guy

> Oh, I should go do something else for a while. It should have TWO brackets :(

Hahaha.. that's where I'm at right now! I'm going to shelve this for a while. I just know it's going to turn into one of those insane "Oh, unix needed some crazy flag set during cmake or php won't be able to locate gpg2" kind of outcomes.

--
Posted on Rocksolid Light

vga256 wrote:

> I should have clarified earlier - no errors from gpg, gnupghome is set correctly, and I have both private and public keys stored for [ultimate] tomo@tomo.dialup.cafe

When you type: gpg --list-secret-keys, does it really show up as 'tomo@'?

It should be 'rslight@', which is hardcoded in cron.php around line 85:

if(!is_file($keydir.'/server_pubkey.txt')) {
$domain = 'rslight@'.$rslight_gpg['domain_name'];

The purpose of this is so that a remote server can check EXACTLY your key to see if it already has it. For example, if it has already has a nocem key, say, nocem@domain.com, then you create an rslight key as 'tomo@domain.com', rslight has no way to know which one to check or which one to use, as it can only do a search in it's keys for 'domain.com'.

If the key is 'rslight@domain.com', rslight can search for the entire name, which rules out any other keys from that domain.

--
Retro Guy

> The purpose of this is so that a remote server can check EXACTLY your key to see if it already has it. For example, if it has already has a nocem key, say, nocem@domain.com, then you create an rslight key as 'tomo@domain.com', rslight has no way to know which one to check or which one to use, as it can only do a search in it's keys for 'domain.com'.

> If the key is 'rslight@domain.com', rslight can search for the entire name, which rules out any other keys from that domain.

Gotcha. I had it both as rslight@ and testing as tomo@ to see if it made any difference yesterday, and it didn't.

The failure is way, way, way before rsl even has a chance to begin checking keys.

--
Posted on Rocksolid Light

vga256 wrote:

>> The purpose of this is so that a remote server can check EXACTLY your key to see if it already has it. For example, if it has already has a nocem key, say, nocem@domain.com, then you create an rslight key as 'tomo@domain.com', rslight has no way to know which one to check or which one to use, as it can only do a search in it's keys for 'domain.com'.

>> If the key is 'rslight@domain.com', rslight can search for the entire name, which rules out any other keys from that domain.

> Gotcha. I had it both as rslight@ and testing as tomo@ to see if it made any difference yesterday, and it didn't.

It won't make a difference if you don't have other keys with the same domain. I found this out while doing more testing, and since my sites have a nocem key from one of my domains, mail was failing. I'm currently finishing up some mods to make sure this is fully handled. I'll post again when I believe it's ready, hopefully within an hour or so.

I thought I was done, then applied to all my sites and of course, it immedately failed :) Welcome to software development.

> The failure is way, way, way before rsl even has a chance to begin checking keys.

Yeah, I just wanted to point it out.

Something to consider. In Debian, there are options to install either gnupg or gnupg2. I am running gnupg. Does mac have the same two options?

--
Retro Guy

> Something to consider. In Debian, there are options to install either gnupg or gnupg2. I am running gnupg. Does mac have the same two options?

Are you sure that you're running gnupg1? gnupg1 does not offer the --quick-generate-key option, which is required by the create_gpg_keys.sh script.

same two options with macos (gpg1 and gpg2 via macports and brew package managers). the problem seems to be with php-gnupg, which looked like it compiled properly, but does not properly communicate with gpg2. php-gnupg was not available through any package manager for macos - so I had to compile from source, then manually activate it in php.ini. it shows up as an extension for php82, with php --info.

i'm going to start looking into php-fpm configuration stuff today, and see if php-fpm isn't communicating with gpg2 for some reason.

--
Posted on Rocksolid Light

vga256 wrote:

>> Something to consider. In Debian, there are options to install either gnupg or gnupg2. I am running gnupg. Does mac have the same two options?

> Are you sure that you're running gnupg1? gnupg1 does not offer the --quick-generate-key option, which is required by the create_gpg_keys.sh script.

Here is the output for dpkg (Version 2.2.40 of gnupg != gnupg2):

ii gnupg 2.2.40-1.1

Debian also offers gnupg2, which I do not have installed:

dpkg -l | grep gnupg2 (shows nothing)

> same two options with macos (gpg1 and gpg2 via macports and brew package managers). the problem seems to be with php-gnupg, which looked like it compiled properly, but does not properly communicate with gpg2. php-gnupg was not available through any package manager for macos - so I had to compile from source, then manually activate it in php.ini. it shows up as an extension for php82, with php --info.

I know nothing about macosx other than it's relation to bsd (which is nice). I did find this page, but I have no idea if it's useful to you: https://gnupg.org/download/

--
Retro Guy

> I know nothing about macosx other than it's relation to bsd (which is nice). I did find this page, but I have no idea if it's useful to you: https://gnupg.org/download/

Son of a ......

.. on a complete random guess, i downloaded the binary installer offered for Mac OS X at gnupg.org..
.. and suddenly I'm getting correct output:
[protocol] => 0 [file_name] => /usr/local/gnupg-2.4/bin/gpg [home_dir] => /Users/tomo/tomobbs/www/common/../../config/.gnupg

apparently the macports package manager borked my gpg 2.x install - but who knows how, since it ran just fine from the CLI.

It's still not encrypting the message, but at least php-gpg is now correctly finding the gpg binary and the home dir, after I force those variables using gnupg_init(file_name, home_dir)

one step in the right direction!

--
Posted on Rocksolid Light

vga256 wrote:

> It's still not encrypting the message, but at least php-gpg is now correctly finding the gpg binary and the home dir, after I force those variables using gnupg_init(file_name, home_dir)

Is this when trying to send a key notification post (automatic), or when trying to send an actual mail message to a destination user?

Maybe try to hard code the pgp keys as a test, and of course make sure you have those keys in your keyring.

--
Retro Guy

..an inch an hour, two feet a day..

I've now got public key retrieval working on both machines:
machine 1:
Aug 10 20:40:23 tomonet Domain Match: bbs.tomo.city
Aug 10 20:40:23 tomonet New PGP Key added for: bbs.tomo.city Domain: bbs.tomo.city Fingerprint

machine 2:
Domain Match: tomo.dialup.cafe
Aug 10 19:44:31 tomonet New PGP Key added for: tomo.dialup.cafe Domain: tomo.dialup.cafe Fingerprint

@@RSL BBSMAIL notice is being copied between machines to .shared.test

Mail is not yet being imported into the local user's mailbox for some reason, but that's basically the final step. almost there!

The problem I was having with automatic key retrieval over http:// turned out to be a bad/incorrect certificate on Machine 2. My nginx install automatically upgrades all http:// calls to https://, and I had an incorrect certificate. There was no error output from mail.php->retrieve_key->$import, which was failing silently after its http call using file_get_contents().

--
Posted on Rocksolid Light

vga256 wrote:

> ..an inch an hour, two feet a day..

> I've now got public key retrieval working on both machines:
> machine 1:
> Aug 10 20:40:23 tomonet Domain Match: bbs.tomo.city
> Aug 10 20:40:23 tomonet New PGP Key added for: bbs.tomo.city Domain: bbs.tomo.city Fingerprint

> machine 2:
> Domain Match: tomo.dialup.cafe
> Aug 10 19:44:31 tomonet New PGP Key added for: tomo.dialup.cafe Domain: tomo.dialup.cafe Fingerprint

> @@RSL BBSMAIL notice is being copied between machines to .shared.test

> Mail is not yet being imported into the local user's mailbox for some reason, but that's basically the final step. almost there!

That sounds great! I did see your posts that included an encrypted message in your test group (I checked your site install) and was happy to see it.

Please note the the current interBBS_mail.php and mail.php in messaging branch include features and fixes I made this morning.

Also, if you apply those, gpg.conf has a minor change. $rslight_gpg['from_email'] is now forced to a specific value:

/* Set 'enable' to '1' to verify you have configured
* this file, and are ready to enable gpg key creation
* for interBBS mail features.
*
* This does NOT enable/disable NoCeM. NoCeM is
* enabled in rslight.inc.php, but it DOES depend
* on $rslight_gpg['gnupghome'] below.
*/
$rslight_gpg['enable'] = '0';

/* YOU MUST CONFIGURE 'domain_name' to your site
* domain name
*/
$rslight_gpg['domain_name'] = "www.example.com";

// What nntp group to use to share mail data
$rslight_gpg['nntp_group'] = "rocksolid.shared.encryption";

// A real contact email address
$rslight_gpg['contact'] = "admin@example.com";

/* Below settings need not be changed if you are
* ok with defaults
*/
// Where your .gpg data is kept
$rslight_gpg['gnupghome'] = $config_dir."/.gnupg";

// Don't change this
$rslight_gpg['from_email'] = "rslight@".$rslight_gpg['domain_name'];

--
Retro Guy