Update configs and add kill script

Hi,
I made two small updates in this PR:

Update sample configs to make network slices info consistent across NFs.
Add script force_kill.sh to quickly kill all NFs and remove the default gtp virtual interface.

Hi @free5gc-org,
Thanks for merging, please also review PRs in nas, smf, upf, webconsole repositories when you have time.
Thanks!


Features added for new release

Checklist

[ ] Tests have been written/updated (if necessary)

[ ] All tests are passing

[ ] Docs have been updated (if necessary)
[ ] Updated Linear issue to In Review

Description
The following bugs / functionalities have been added:

Combine list of cloud feeds into into the device list overview
Fix building numbers shown on 'Measurements' screen
Fix 4th tick after WiFi reset: upload date needs to be newer than time of reset
Fix app waiting indefinitely at 4th step after Wi-Fi reset

Linked Issues
Additional context

I force pushed a rebase to change commit messages for some commits. The messages adhere to conventional commits now, and will be used in the changelog for the new version.


meta

feature tracking:

[x] aircraft search (id, shortname, name, *) and suggest, with engine priority / spd mods
[x] airport search (id, iata, icao, name, *) and suggest
[x] route creation (ap > ap)
[x] aircraft-route creation (ap > ap + ac)

[x] alliance contribution estimation
[x] #7
[x] raise error if realism and runway is too short

[x] route research (ap + ac)
[x] user: default, settings editing

[x] 4x

[x] campaign: parsing, load estimation
[x] #2
[ ] #3
[x] #4
[x] #5
[x] #6

nice to have:

[x] refactor: move PaxConfig and CargoConfig within the Aircraft struct.
[x] add repair training points
[ ] remove dynamically linked duckdb and replace with static arrow
[ ] do not raise std::exception if id0 == id1 in Route.create(id0, id1).
[ ] use gperf for get_airport_by_{str}
[ ] allow a388[eid:XXX] instead of only a388[0]
[ ] invalidate Campaign if parsing fails
[x] use templates

v0.2 feature tracking:

[x] airport search and suggest
[x] aircraft search and suggest
[ ] route creation (ap > ap)
[ ] aircraft-route creation (ap > ap, ac)
[ ] route research (ap > *, ac)


RFC7250 (RPK) support (Fixes #6929)

Add support for the RFC7250 extensions, allows the use of only private
keys for connection (i.e. certs not needed).
Fixes #6929
Replacement for #16620 (since github doesn't allow changing the source of a PR)
Add APIs
Add unit tests
Add documentation
Add s_client/s_server support

Checklist

[X] documentation is added or updated
[X] tests are added or updated

This PR is in a state where it requires action by @openssl/omc but the last update was 30 days ago

This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago

This PR is in a state where it requires action by @openssl/otc but the last update was 61 days ago

This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago

This PR is in a state where it requires action by @openssl/otc but the last update was 61 days ago

Had to reconcile with Certificate Compression. Since RPK is an explicit opt-in, certificate compression is opt-out, and RPKs are smaller than compressed certificates, RPKs are preferred over compressed certificates. In addition, RPKs will not be compressed (i.e. you won't find a RPK in a Compressed Certificate message).

This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago

ping @openssl/committers ?

The upper layer APis in this PR are heading down the wrong PATH and need to be reimplemented
We all already have a well established mechanism for verifying certificate chains by just their public KEY material. This is takes the form of DANE-EE(3) with a selector of SPKI(1).  The mtype field can then be the full SPKI (DER) public key, or a SHA2-256 or SHA2-512 hash thereof.  The caller can specify multiple acceptable keys by injecting multiple TLSA records into the SSL handle.  See SSL_CTX_dane_enable(3) for details.
Note that the DANE support in OpenSSL does not perform any DNS lookups.  The TLSA records configured for the SSL session can come from any source, including computed from explicit key material as in the DANE tests.
All the criticism aside, it is nice to see the low-level support implemented for raw public keys, this is a good time to hook it into the DANE layers of the library, improving both the RPK support and DANE.

Thanks @vdukhovni, I'm not familiar with DANE. Given that RPKs are just that, a single key, will using DANE work without a chain?
That being said, I'm a bit confused as to why DANE doesn't do DNS lookups, or how could handle keys that don't have any other identifying information.
DANE is mentioned as only one possible method of obtaining a public key for verification in RFC7250, but not the only method. It seems odd to me to have to configure DANE in order to use something as simple as raw public keys; the current APIs shouldn't preclude the use of DANE, but it also doesn't require the use of DANE. All references in RFC7250 mention acquiring a public key out-of-band (including DANE out-of-band). It's something I'll have to research.

Thanks @vdukhovni, I'm not familiar with DANE. Given that RPKs are just that, a single key, will using DANE work without a chain?

Yes, DANE TLSA "3 1 X" records are validated against just the peer's public key, without any reference to a certificate chain.
The longer descriptive form RFC7218 of these is:

3 1 0:  DANE-EE(3) SPKI(1) Full(0) - Match the full peer public key.
3 1 1:  DANE-EE(3) SPKI1(1) SHA2-256(1) - Match the SHA2-256 hash of the peer public key
3 1 2:  DANE-EE(3) SPKI(1) SHA2-512(2) - Match the SHA2-512 hash of the peer public key

So, yes. RPK's can be verified with DANE, and this is in fact intended in RFC7250 Introduction

That being said, I'm a bit confused as to why DANE doesn't do DNS lookups, or how could handle keys that don't have any other identifying information.

DANE applications may do DNS lookups, but OpenSSL does not, the application is expected to do that and pass any such records (real or synthetic) to the OpenSSL API, which can then validate the peer handshake.  So the strongly preferred way to add RPK support is to extend the DANE API to support RPKs, and have the application configure validation via TLSA records.

DANE is mentioned as only one possible method of obtaining a public key for verification in RFC7250, but not the only method.

That's just about using DNS as the source, but nothing about OpenSSL requires the TLSA records to come from DNS, they are just an existing form of providing trust anchors or leaf keys.  Therefore, use TLSA record for non-WebPKI trust anchors and trusted EE keys.

It seems odd to me to have to configure DANE in order to use something as simple as raw public keys;

You're missing the point. The DANE support in OpenSSL is an abstraction over ways to specify non-WebPKI trust. It can and is being used for direct public key trust in, for example, Postfix, where the DANE API also validates locally configured fingerprints...

the current APIs shouldn't preclude the use of DANE, but it also doesn't require the use of DANE.

Don't confuse use of DNSSEC lookup to get TLSA records, with the OpenSSL support for consuming them as a format for trust information.  Make the RPK implementation ride on top of that interface, which then also extends DANE support to (optionally if also enabled) work with RPKs.

@vdukhovni thanks for the info!

In include/internal/dane.h you'll find:
struct ssl_dane_st {
    struct dane_ctx_st *dctx;
    STACK_OF(danetls_record) *trecs;
    STACK_OF(X509) *certs;      /* DANE-TA(2) Cert(0) Full(0) certs */
    danetls_record *mtlsa;      /* Matching TLSA record */
    X509           *mcert;      /* DANE matched cert */
    uint32_t        umask;      /* Usages present */
    int             mdpth;      /* Depth of matched cert */
    int             pdpth;      /* Depth of PKIX trust */
    unsigned long   flags;      /* feature bitmask */
};

which presently can only report a matched certificate via the mcert field. It would now need to be able report a matched public key via a newmspki field and associated accessor.  Enabling DANE should not automatically enable RPK support, but it should be just a single additional call to enable that option, and then if the peer happens to have raw public keys, great, but if not, a full cert with the same key will also work.
Enabling use of RPK to authenticate to a remote peer is orthogonal to DANE, just configure a key pair for one or more algorithms and enable the extension. Ideally also provide fallback (possibly self-signed) certificates if peers that don't do RPK are supported.

RPK is negotiated; both peers have to support the option. So, there's no chance that a client will receive a RPK unless they specifically ask/allow for it.
And to be clear, a raw public key should never match/verify a certificate (and vice-versa). A RPK should only ever match/verify another RPK. For ease-of-use, the RPK can be extracted from an assigned certificate; there's an option to just assign the private key to determine what the RPK is.
Before I go to far into DANE, I want some some feedback from @mattcaswell @t8m @paulidale if DANE is the right approach for authenticating peer RPKs. It just feels alien to me to introduce DANE and it's APIs in order to use RPK.

RPK is negotiated; both peers have to support the option. So, there's no chance that a client will receive a RPK unless they specifically ask/allow for it.

Correct, and DANE-enabled applications, are particularly good candidates for using RPKs when the TLSA records in hand are all of the DANE-EE(3) SPKI(1) [012] variety.  And there is also opportunistic RPK, where the client is willing (prefers) to use RPKs, but will settle for certificates if that's all the peer supports. And in this case DANE is a particularly good fit, because it would match either an actual RPK, or extract and match the key from the certificate, and the DANE TLSA records could come from DNSSEC or from some local policy mechanism (e.g. Postfix "fingerprint" security level).

And to be clear, a raw public key should never match/verify a certificate (and vice-versa). A RPK should only ever match/verify another RPK. For ease-of-use, the RPK can be extracted from an assigned certificate; there's an option to just assign the private key to determine what the RPK is.

Requiring an explicit public key to match the peer's RPK is too restrictive. It should be possible to match it by its digest, and the digest or full key could come from a variety of sources. Using the existing validation framework improves both the flexibility of RPK and the available use cases for DANE.
Since the client can offer to use either of RPK or X.509, whichever the server prefers, expressing the matching criteria via DANE is particularly natural, because the server may in fact present a certificate anyway, and it is simplest if the client's verification parameters are the same either way.

Before I go to far into DANE, I want some some feedback from @mattcaswell @t8m @paulidale if DANE is the right approach for authenticating peer RPKs. It just feels alien (overkill?) to me to introduce DANE and it's APIs in order to use RPK.

You're looking at the problem too narrowly.  I can help you if something is unclear, but I am quite sure that extending DANE with RPKs and RPKs with DANE is the right win-win design.
Sure, once a handshake actually ends up using RPKs (in or the other direction), then the receiving peer would not call X509_verify_cert(3).  Instead it would call a new X509_verify_rpk(3) or similar, and verification would be strictly limited to the provided "3 1 X" TLSA records.  A DANE client would only enable RPK when all TLSA records are of that form, and when it is prepared to end up with no certificate at the conclusion of the handshake (requires a modest amount of new code in the client).

Requiring an explicit public key to match the peer's RPK is too restrictive. It should be possible to match it by its digest, and the digest or full key could come from a variety of sources. Using the existing validation framework improves both the flexibility of RPK and the available use cases for DANE.

What I was trying to say, is that it shouldn't (can't) be checked against a cert or chain. I agree that a hash is sufficient.

Instead it would call a new X509_verify_rpk(3) or similar,

This may have been what was missing from your original suggestion. I think I understand you mean by this, but it's confusingly named, given that RPK is independent of X509. ;)
One of the things that has been bothering me is that SSL_dane_enable() requires a basedomain; presumably to check against the certificate, which won't exist in this case. We should not require a domain for RPK. How should this be reconciled?
Note that even if RPK is enabled on a client, it could still receive a certificate, so a DANE client ought to be able to enable RPK if there are any "3 1 X" TLSA records, not just "all". In which case, the client needs to
Does this also work client to server, in terms of mutual authentication? Is the server end able to authenticate a client RPK via the same mechanism? The documentation states that SSL_dane_enable() is called before SSL_connect() which implies that it's meant to be used on the client-side. The server can also receive RPKs from the client, and verification of those should use the same mechanism that the client uses.

Requiring an explicit public key to match the peer's RPK is too restrictive. It should be possible to match it by its digest, and the digest or full key could come from a variety of sources. Using the existing validation framework improves both the flexibility of RPK and the available use cases for DANE.

What I was trying to say, is that it shouldn't (can't) be checked against a cert or chain. I agree that a hash is sufficient.

Of course.

Instead it would call a new X509_verify_rpk(3) or similar,

This may have been what was missing from your original suggestion. I think I understand you mean by this, but it's confusingly named, given that RPK is independent of X509. ;)

Note that the RPK in question is still part of X.509, it is an X.509 SPKI. :-). There's a lot less ASN.1 in a public key, but there is still an algorithm OID and (in some cases) parameters.

One of the things that has been bothering me is that SSL_dane_enable() requires a basedomain; presumably to check against the certificate, which won't exist in this case. We should not require a domain for RPK. How should this be reconciled?

The domain should be set if there is any possibility that the server will instead use a certificate, because the SPKI in the domain is needed for the server to select the right one.  The domain is used to set the client's SNI extension, which IIRC is now essentially required anyway (even with RPK?).  So there's no need to sweat the domain, if there's really nothing suitable available, perhaps allow NULL and update https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L1145-L1161

Note that even if RPK is enabled on a client, it could still receive a certificate, so a DANE client ought to be able to enable RPK if there are any "3 1 X" TLSA records, not just "all". In which case, the client needs to

It would be imprudent of a DANE client to enable RPK when one of the published TLSA records is impossible with RPK. That TLSA record might be the only one that actually works (mid migration from 3 1 X to 2 1 X or 3 0 1, ...).  Sure clients can do imprudent things, but I would not approve a code review of such a client.

Does this also work client to server, in terms of mutual authentication? Is the server end able to authenticate a client RPK via the same mechanism? The documentation states that SSL_dane_enable() is called before SSL_connect() which implies that it's meant to be used on the client-side. The server can also receive RPKs from the client, and verification of those should use the same mechanism that the client uses.

I have not yet tested server-side DANE, but it should work just as well when the parameters are configured before SSL_accept().  There is some IETF work in the "dance" working group to extend DANE to validation of client credentials, and it would be good to iron out any kinks in the server side if present.  Note that it should ideally be possible for the server add TLSA records any time before receiving the client certificate, because it could in some cases learn the location of the client's TLSA records via an extension! I may need to help you here, but there's no fundamental asymmetry, the TLSA records just have to be loaded by the time the peer creds need to be verified, and "late" initialisation should be possible.

The domain should be set if there is any possibility that the server will instead use a certificate, because the SPKI in the domain is needed for the server to select the right one. The domain is used to set the client's SNI extension, which IIRC is now essentially required anyway (even with RPK?). So there's no need to sweat the domain, if there's really nothing suitable available, perhaps allow NULL and update https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L1145-L1161

Note that on the server side we really should not require the domain, and setting the SNI name makes no sense, that code would need a tweak to make the basedomain optional, and to only set the SNI name if the SSL handle is not a server handle.
The DANE code might change in minor ways as a result, this should largely be an improvement.

And, once you're close to done, I'd like to try adding RPK support to Postfix, that'd be a good test case.

@vdukhovni don't get me wrong, I do appreciate your feedback. I'm still a bit hesitant on requiring the use of DANE APIs in order to use RPKs. As you alluded to in one of your comments, perhaps making it more about CertificateType will make it easier to accept.
P.S. I recently changed jobs, so OpenSSL is no longer my priority. It'll just take me longer to make updates.

Perhaps the first step is to move away from the new SSL_OP_ bits and implement a configurable cert type vector?
Then implement X509_verify_rpk(3), which takes the accepted keys via X509_VERIFY_PARAM, but checks a single peer key, and supports a new verify_rpk() callback.
Then make SSL_dane_enable more server-friendly (not frob the SNI in server mode, and tolerate missing base domains, which also means no name checks, but that's typical with client certs unless the server has some way to know in advance what client name to expect).
Then implement support for DANE TLSA record support in X509_verify_rpk(), and return of the DANE status (show which TLSA record matched if any).
Finally, provide whichever friendly wrappers are needed to allow users, who don't care that its DANE all the way down, to just provide a set of public keys and have the TLSA records synthesised internally.
Along the way also support multiple candidate peer keys in s_client(1) and s_server(1).

Still need to update s_client/s_serverm but otherwise I think this wraps up the DANE integration.

Thanks.  I'll review promptly.

NIce work, this passes tests, and also passes authentication with
$ openssl s_client -enable_server_rpk -connect localhost:12345  \
    -dane_tlsa_domain server.example \
    -dane_tlsa_rrdata "3 1 1 7fed30eb41db6383924a3879c70fb7ea749b878fff99b73b396127e2b0578fce"

against a server instantiated via:
$ openssl s_server -enable_server_rpk -accept 12345 \
    -key ../openssl/test/certs/ee-key.pem \
    -cert ../openssl/test/certs/ee-cert.pem

Perhaps (at some point) such a server shouldn't have to specify a certificate, and when configured with just a key support only raw public keys, but that can be deferred if too much to take on at present (be able to combine the "-key" and "-nocert" options, provided -enable_server_rpk is also set).
One more thing to note is that the s_client reporting with -brief is too skimpy, for absence of a certificate it also makes no mention of the RPK, or that it passes verification (as one would see with DANE + certs):
# DANE+X509:
$ openssl s_client -brief -connect localhost:12345 \
    -dane_tlsa_domain server.example \
    -dane_tlsa_rrdata "3 1 1 7fed30eb41db6383924a3879c70fb7ea749b878fff99b73b396127e2b0578fce"
Connecting to <IP_ADDRESS>
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=server.example
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK
Verified peername: server.example
DANE TLSA 3 1 1 ...ff99b73b396127e2b0578fce matched EE certificate at depth 0
Server Temp Key: X25519, 253 bits

# DANE+RPK:
$ openssl s_client -brief -enable_server_rpk  -connect localhost:12345 \
    -dane_tlsa_domain  server.example \
    -dane_tlsa_rrdata "3 1 1 7fed30eb41db6383924a3879c70fb7ea749b878fff99b73b396127e2b0578fce"
Connecting to <IP_ADDRESS>
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
No peer certificate
Server Temp Key: X25519, 253 bits

With a few changes (below), I am able to get the more informative (ECDSA server key for a change this time):
$ openssl s_client -brief -enable_server_rpk -connect localhost:12345 \
    -dane_tlsa_domain server.example \
    -dane_tlsa_rrdata "3 1 1 80d41bf1dc047e0799a50cd501bf9995658108759686869d0cf191117b8b4208"
Connecting to <IP_ADDRESS>
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Server used raw public key
Signature type: ECDSA
Verification: OK
DANE TLSA 3 1 1 ...9686869d0cf191117b8b4208 matched EE raw public key
Server Temp Key: X25519, 253 bits

The required patch (which also addresses my comment about updating pdpth being not needed in the RPK case, and it is in fact mdpth that has to be set) is:
--- a/crypto/x509/x509_vfy.c
+++ b/crypto/x509/x509_vfy.c
@@ -3071,7 +3071,7 @@ static int dane_match_rpk(X509_STORE_CTX *ctx, EVP_PKEY *rpk)
         }
         if (cmplen == t->dlen && memcmp(cmpbuf, t->data, cmplen) == 0) {
             matched = 1;
-            dane->pdpth = 1;
+            dane->mdpth = 0;
             dane->mtlsa = t;
             break;
         }
--- a/apps/lib/s_cb.c
+++ b/apps/lib/s_cb.c
@@ -1172,6 +1172,7 @@ static char *hexencode(const unsigned char *data, size_t len)
 void print_verify_detail(SSL *s, BIO *bio)
 {
     int mdpth;
+    X509 *mcert;
     EVP_PKEY *mspki;
     long verify_err = SSL_get_verify_result(s);

@@ -1187,7 +1188,7 @@ void print_verify_detail(SSL *s, BIO *bio)
         BIO_printf(bio, "Verification error: %s\n", reason);
     }

-    if ((mdpth = SSL_get0_dane_authority(s, NULL, &mspki)) >= 0) {
+    if ((mdpth = SSL_get0_dane_authority(s, &mcert, &mspki)) >= 0) {
         uint8_t usage, selector, mtype;
         const unsigned char *data = NULL;
         size_t dlen = 0;
@@ -1207,12 +1208,15 @@ void print_verify_detail(SSL *s, BIO *bio)
             hexdata = hexencode(data + dlen - TLSA_TAIL_SIZE, TLSA_TAIL_SIZE);
         else
             hexdata = hexencode(data, dlen);
-        BIO_printf(bio, "DANE TLSA %d %d %d %s%s %s at depth %d\n",
+        BIO_printf(bio, "DANE TLSA %d %d %d %s%s matched %s",
                    usage, selector, mtype,
                    (dlen > TLSA_TAIL_SIZE) ? "..." : "", hexdata,
                    (mspki != NULL) ? "signed the certificate" :
-                   mdpth ? "matched TA certificate" : "matched EE certificate",
-                   mdpth);
+                   mdpth ? "TA" : "EE");
+        if (mcert)
+            BIO_printf(bio, " certificate at depth %d\n", mdpth);
+        else
+            BIO_printf(bio, " raw public key\n");
         OPENSSL_free(hexdata);
     }
 }
@@ -1220,17 +1224,16 @@ void print_verify_detail(SSL *s, BIO *bio)
 void print_ssl_summary(SSL *s)
 {
     const SSL_CIPHER *c;
-    X509 *peer;
+    X509 *peer = SSL_get0_peer_certificate(s);
+    EVP_PKEY *peer_rpk = SSL_get0_peer_rpk(s);
+    int nid;

     BIO_printf(bio_err, "Protocol version: %s\n", SSL_get_version(s));
     print_raw_cipherlist(s);
     c = SSL_get_current_cipher(s);
     BIO_printf(bio_err, "Ciphersuite: %s\n", SSL_CIPHER_get_name(c));
     do_print_sigalgs(bio_err, s, 0);
-    peer = SSL_get0_peer_certificate(s);
     if (peer != NULL) {
-        int nid;
-
         BIO_puts(bio_err, "Peer certificate: ");
         X509_NAME_print_ex(bio_err, X509_get_subject_name(peer),
                            0, get_nameopt());
@@ -1240,6 +1243,11 @@ void print_ssl_summary(SSL *s)
         if (SSL_get_peer_signature_type_nid(s, &nid))
             BIO_printf(bio_err, "Signature type: %s\n", get_sigtype(nid));
         print_verify_detail(s, bio_err);
+    } else if (peer_rpk != NULL) {
+        BIO_printf(bio_err, "Server used raw public key\n");
+        if (SSL_get_peer_signature_type_nid(s, &nid))
+            BIO_printf(bio_err, "Signature type: %s\n", get_sigtype(nid));
+        print_verify_detail(s, bio_err);
     } else {
         BIO_puts(bio_err, "No peer certificate\n");
     }

Separately from this PR, it would be good if the key bit count (RSA) or curve name (ECDSA) were also reported.

By the way, I also have a prototype Postfix with RPK support.  Too early to integrate into the Postfix release, since this PR is not yet merged and the API could change, or this could fail to land in 3.2, ... but perhaps some time in the Postfix 3.9 dev cycle (later this year I hope) it may become possible to merge.
$ posttls-finger <mydomain>
posttls-finger: <mymx>[<IP_ADDRESS>]:25: raw public key fingerprint=<...>
posttls-finger: <mymx>[<IP_ADDRESS>]:25: Matched DANE raw public key: 3 1 1 <...>
posttls-finger: Verified TLS connection established to <mymx>[<IP_ADDRESS>]:25:
    TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
    key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256

$ git log -n1 --stat
commit 9198a5c64aa5ae365cc0dce29614b43ad500ba8a (HEAD -> rpk)
Author: Viktor Dukhovni<EMAIL_ADDRESS>Date:   Fri Jan 20 14:36:12 2023 -0500

    RPK support

 postfix/src/posttls-finger/posttls-finger.c |  2 +-
 postfix/src/smtpd/smtpd_check.c             | 16 ++++++++++++----
 postfix/src/tls/tls.h                       |  3 ++-
 postfix/src/tls/tls_client.c                | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
 postfix/src/tls/tls_dane.c                  | 55 +++++++++++++++++++++++++++++++++++++++++++++----------
 postfix/src/tls/tls_fprint.c                | 50 +++++++++++++++++---------------------------------
 postfix/src/tls/tls_misc.c                  | 32 ++++++++++++++++++++------------
 postfix/src/tls/tls_server.c                | 40 ++++++++++++++++++++++++++++++++++++++--
 8 files changed, 211 insertions(+), 76 deletions(-)

By the way, I also have a prototype Postfix with RPK support. Too early to integrate into the Postfix release, since this PR is not yet merged and the API could change, or this could fail to land in 3.2, ... but perhaps some time in the Postfix 3.9 dev cycle (later this year I hope) it may become possible to merge.
$ posttls-finger <mydomain>
posttls-finger: <mymx>[<IP_ADDRESS>]:25: raw public key fingerprint=<...>
posttls-finger: <mymx>[<IP_ADDRESS>]:25: Matched DANE raw public key: 3 1 1 <...>
posttls-finger: Verified TLS connection established to <mymx>[<IP_ADDRESS>]:25:
    TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
    key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256

$ git log -n1 --stat
commit 9198a5c64aa5ae365cc0dce29614b43ad500ba8a (HEAD -> rpk)
Author: Viktor Dukhovni<EMAIL_ADDRESS>Date:   Fri Jan 20 14:36:12 2023 -0500

    RPK support

 postfix/src/posttls-finger/posttls-finger.c |  2 +-
 postfix/src/smtpd/smtpd_check.c             | 16 ++++++++++++----
 postfix/src/tls/tls.h                       |  3 ++-
 postfix/src/tls/tls_client.c                | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
 postfix/src/tls/tls_dane.c                  | 55 +++++++++++++++++++++++++++++++++++++++++++++----------
 postfix/src/tls/tls_fprint.c                | 50 +++++++++++++++++---------------------------------
 postfix/src/tls/tls_misc.c                  | 32 ++++++++++++++++++++------------
 postfix/src/tls/tls_server.c                | 40 ++++++++++++++++++++++++++++++++++++++--
 8 files changed, 211 insertions(+), 76 deletions(-)

That would be especially useful, as DANE (and more specifically the SPKI selector) is much more common in the SMTP space.

That would be especially useful, as DANE (and more specifically the SPKI selector) is much more common in the SMTP space.
Yes, SMTP, and especially with DANE-EE(3) SPKI(1) TLSA records, is very well suited for deploying RPK. The Postfix code is mostly ready now, the gating factor will be how quickly this PR will land in an OpenSSL release. Until this is part of a release branch, the Postfix feature will have to remain unreleased. With additional fine-tuning and docs the footprint comes out larger, and now also supports RPK in the client-to-server direction and at the fingerprint TLS security level when peer credential matching is public-key based.

9fcbd0e0f (HEAD -> rpk, o/rpk) WIP: RPK support
 postfix/man/man8/smtp.8                     |   5 +++++
 postfix/man/man8/smtpd.8                    |   4 ++++
 postfix/man/man8/tlsproxy.8                 |   4 ++++
 postfix/mantools/postlink                   |   4 ++++
 postfix/proto/postconf.proto                | 117 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 postfix/src/global/Makefile.in              |   6 +++---
 postfix/src/global/fpt_mask.c               |  89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 postfix/src/global/fpt_mask.h               |  39 ++++++++++++++++++++++++++++++++++
 postfix/src/global/mail_params.h            |  14 +++++++++++++
 postfix/src/posttls-finger/posttls-finger.c |  28 ++++++++++++++++++-------
 postfix/src/smtp/lmtp_params.c              |   1 +
 postfix/src/smtp/smtp.c                     |  19 +++++++++++++++++
 postfix/src/smtp/smtp.h                     |  11 ++++++++++
 postfix/src/smtp/smtp_params.c              |   1 +
 postfix/src/smtp/smtp_proto.c               |   2 ++
 postfix/src/smtp/smtp_tls_policy.c          |   8 ++++---
 postfix/src/smtpd/smtpd.c                   |  24 ++++++++++++++++++++-
 postfix/src/smtpd/smtpd_check.c             |  15 +++++++++----
 postfix/src/tls/tls.h                       |  23 +++++++++++++-------
 postfix/src/tls/tls_client.c                | 151 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------
 postfix/src/tls/tls_dane.c                  |  82 +++++++++++++++++++++++++++++++++++++++++++++++------------------------
 postfix/src/tls/tls_fprint.c                |  53 ++++++++++++++++++----------------------------
 postfix/src/tls/tls_misc.c                  |  94 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
 postfix/src/tls/tls_proxy.h                 |   5 +++--
 postfix/src/tls/tls_proxy_client_print.c    |   1 +
 postfix/src/tls/tls_proxy_client_scan.c     |   3 ++-
 postfix/src/tls/tls_server.c                |  74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----------
 postfix/src/tlsproxy/tlsproxy.c             |  23 ++++++++++++++++++++

(Commit c5cf93a78bed38ecd050d9117b2614670e89dff4)
Testing the DTLS 1.2 interoperability with Eclipse/Californium with:
./openssl s_client -debug -dtls1_2 -enable_server_rpk -connect californium.eclipseprojects.io:5684

results in an "Decode Error".
rfc7250.pcapng.gz
Not sure, what exactly is considered to be the error. Maybe someone can check the capture.
RFC7250 3. Structure of the Raw Public Key Extension
opaque ASN.1Cert<1..2^24-1>;

   struct {
       select(certificate_type){

            // certificate type defined in this document.
            case RawPublicKey:
              opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;

           // X.509 certificate defined in [RFC 5246](https://www.rfc-editor.org/rfc/rfc5246)
           case X.509:
             ASN.1Cert certificate_list<0..2^24-1>;

           // Additional certificate type based on
           // "TLS Certificate Types" subregistry
       };
   } Certificate;

    Figure 1: Certificate Payload as a Container for the Raw Public Key

A couple of years ago, some encoded RawPublicKey case as a list with 1 certificate. I didn't found it again, but there was a discussion which clarifies, that the RawPublicKey case uses no list but the certificate directly.

Testing the DTLS 1.2 interoperability with Eclipse/Californium with:
./openssl s_client -debug -dtls1_2 -enable_server_rpk -connect californium.eclipseprojects.io:5684

results in an "Decode Error".

Good catch.  I think the below should fix it:
--- a/ssl/statem/statem_lib.c
+++ b/ssl/statem/statem_lib.c
@@ -1054,7 +1054,7 @@ int tls_process_rpk(SSL_CONNECTION *sc, PACKET *pkt, EVP_PKEY **peer_rpk)
     RAW_EXTENSION *rawexts = NULL;
     PACKET extensions;
     PACKET context;
-    unsigned long cert_list_len, spki_len = 0;
+    unsigned long spki_len = 0;
     const unsigned char *spki, *spkistart;
     SSL_CTX *sctx = SSL_CONNECTION_GET_CTX(sc);

@@ -1083,35 +1083,26 @@ int tls_process_rpk(SSL_CONNECTION *sc, PACKET *pkt, EVP_PKEY **peer_rpk)
         }
     }

-    if (!PACKET_get_net_3(pkt, &cert_list_len)
-            || PACKET_remaining(pkt) != cert_list_len) {
+    /* RPK consists of a single non-empty entry, not a list. */
+    if (!PACKET_get_net_3(pkt, &spki_len) || spki_len == 0) {
         SSLfatal(sc, SSL_AD_DECODE_ERROR, SSL_R_LENGTH_MISMATCH);
         goto err;
     }
-
-    /* RPK only admits a single CertificateEntry in the list, so no loop. */
-    if (!PACKET_get_net_3(pkt, &spki_len)) {
+    if (!PACKET_get_bytes(pkt, &spki, spki_len)) {
         SSLfatal(sc, SSL_AD_DECODE_ERROR, SSL_R_LENGTH_MISMATCH);
         goto err;
     }
-    if (spki_len != 0) {
-        if (!PACKET_get_bytes(pkt, &spki, spki_len)) {
-            SSLfatal(sc, SSL_AD_DECODE_ERROR, SSL_R_LENGTH_MISMATCH);
-            goto err;
-        }
-        spkistart = spki;
-        if ((pkey = d2i_PUBKEY_ex(NULL, &spki, spki_len, sctx->libctx, sctx->propq)) == NULL
-            || spki != (spkistart + spki_len)) {
-            SSLfatal(sc, SSL_AD_DECODE_ERROR, SSL_R_LENGTH_MISMATCH);
-            goto err;
-        }
-        if (EVP_PKEY_missing_parameters(pkey)) {
-            SSLfatal(sc, SSL_AD_INTERNAL_ERROR,
-                     SSL_R_UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS);
-            goto err;
-        }
+    spkistart = spki;
+    if ((pkey = d2i_PUBKEY_ex(NULL, &spki, spki_len, sctx->libctx, sctx->propq)) == NULL
+        || spki != (spkistart + spki_len)) {
+        SSLfatal(sc, SSL_AD_DECODE_ERROR, SSL_R_LENGTH_MISMATCH);
+        goto err;
+    }
+    if (EVP_PKEY_missing_parameters(pkey)) {
+        SSLfatal(sc, SSL_AD_INTERNAL_ERROR,
+                 SSL_R_UNABLE_TO_FIND_PUBLIC_KEY_PARAMETERS);
+        goto err;
     }
-    /* else empty RPK */

     /* Process the Extensions block */
     if (SSL_CONNECTION_IS_TLS13(sc)) {
@@ -1204,21 +1195,10 @@ static int tls_add_rpk(SSL_CONNECTION *sc, WPACKET *pkt, CERT_PKEY *cpk)

 unsigned long tls_output_rpk(SSL_CONNECTION *sc, WPACKET *pkt, CERT_PKEY *cpk)
 {
-    if (!WPACKET_start_sub_packet_u24(pkt)) {
-        SSLfatal(sc, SSL_AD_INTERNAL_ERROR, ERR_R_INTERNAL_ERROR);
-        return 0;
-    }
-
     if (!tls_add_rpk(sc, pkt, cpk)) {
         /* SSLfatal() already called */
         return 0;
     }
-
-    if (!WPACKET_close(pkt)) {
-        SSLfatal(sc, SSL_AD_INTERNAL_ERROR, ERR_R_INTERNAL_ERROR);
-        return 0;
-    }
-
     return 1;
 }

FWIW, the two proposed patches upthread:

https://github.com/openssl/openssl/pull/18185#issuecomment-1398006252
https://github.com/openssl/openssl/pull/18185#issuecomment-1399672704

can also be found in the two commits at: https://github.com/vdukhovni/openssl/commits/rpk-fixup

On the IETF TLS WG mailing list, a question was asked about EC point forms. My impression is that the RPK code in this PR is EC-point-form-agnostic. That is, any point form that d2i_PUBKEY groks is accepted from the peer, and the point form sent to the peer is the default point form of the underlying EVP_PKEY (hopefully typically coincident with the expected form for the given curve in TLS 1.3)
My questions are:

Is the above correct?
Should there be any effort to ensure that we send the expected point form to the peer, in case the private key we have is for some reason not in that form?
Should there be any effort to reject peer keys in an "unexpected" point form?

FWIW, there is no negotiation of point forms in TLS 1.3, just one form per curve, but there was a now deprecated negotiation of point forms in TLS <= 1.2.  How should all this be handled?
Cc: @mattcaswell

Personally, I think it is worth considering only supporting new functionality in TLS 1.3 if that makes it easier. That's sort of the point of dropping those features.

Personally, I think it is worth considering only supporting new functionality in TLS 1.3 if that makes it easier. That's sort of the point of dropping those features.

TLS 1.2 will be with us for quite some time. Especially in the sort of low-power applications that are interested in RPK. So no, RPK should not be TLS 1.3 only.  However, EC point form negotiation could perhaps be minimised to just the required forms unless there is established practice of using compressed forms. Basically, we should broadly interoperate with the existing implementations of RPK.

TLS 1.2 will be with us for quite some time. Especially in the sort of low-power applications that are interested in RPK.

Though RPK wasn't that often implemented (I know, GnuTLS, Eclipse/tinydtls, Eclipse/Californium), I'm not sure how many of them support other formats than "uncompressed". At least Eclipse/tinydtls and Eclipse/Californium doesn't.

TLS 1.2 will be with us for quite some time. Especially in the sort of low-power applications that are interested in RPK.

Though RPK wasn't that often implemented (I know, GnuTLS, Eclipse/tinydtls, Eclipse/Californium), I'm not sure how many of them support other formats than "uncompressed". At least Eclipse/tinydtls and Eclipse/Californium doesn't.

Good to know that non-default point forms may not need to be supported (TLS 1.2). The remaining question is whether to add any code to ensure compliance (in case the local key is somehow in a non-default form) at least when sending. I am not sure that it makes sense to reject a remote key that is compressed if we're able to handle that.

I've tested the DTLS 1.2 interoperability with Eclipse/Californium.
Using keys with secp256r1 works in both client/server combinations.
Using keys with ed25519 works only with openssl client, but not with the openssl server.
(But ed25519/openssl server fails as well using x509 and no rpk. So it seems to be a more general issue.)

On the IETF TLS WG mailing list, a question was asked about EC point forms. My impression is that the RPK code in this PR is EC-point-form-agnostic. That is, any point form that d2i_PUBKEY groks is accepted from the peer, and the point form sent to the peer is the default point form of the underlying EVP_PKEY (hopefully typically coincident with the expected form for the given curve in TLS 1.3)
My questions are:

Is the above correct?

Yes. d2i_PUBKEY()/i2d_PUBKEY() is used, so however that groks/exports keys is what is used.

I've tested the DTLS 1.2 interoperability with Eclipse/Californium.
Using keys with secp256r1 works in both client/server combinations. Using keys with ed25519 works only with openssl client, but not with the openssl server. (But ed25519/openssl server fails as well using x509 and no rpk. So it seems to be a more general issue.)

That's (mostly) good news thanks!  I am somewhat concerned about the OpenSSL ed25519 situation, the OpenSSL client does appear to interoperate with an OpenSSL server that has an ed25519 certificate (TLS 1.2 and 1.3 both work). Do you also see the same? So it seems that the OpenSSL server may be incompatible in some way with other clients. Can you provide any more details?  Do you see the same issue with OpenSSL 3.0 (release, rather than dev branch)? Perhaps a separate issue should be opened to track this if it appears to be an OpenSSL 3.x issue?

I've used ed25519 certificates (with nginx acting as server) without any apparent issue.

Perhaps a separate issue should be opened to track this if it appears to be an OpenSSL 3.x issue?

I will go for that. Maybe it's only a question of provided arguments.

About Ed25519, the issue seems to affect only DTLS, see issue #20122.

I've used ed25519 x509 certificates (with nginx and OpenSSL 3 acting as server) without any apparent issue.

Seems to affect only DTLS, TLS is working.

https://mta.openssl.org/pipermail/openssl-users/2019-November/011582.html

https://mailarchive.ietf.org/arch/msg/tls/CaXLm2nQn0XXQZZc61q-scVkduY/

OK, good to know. (Seems to stick on "selective words", anyway, it saves my time testing something, which is not considered.)

Commit bb42e91a1d8c8ec1a12758c252eaeeaedc1f05b4
I added a interop test for "no suitable client certificate" using an openssl client and californium server.
rpk_empty.pcapng.gz
Openssl sends a Certificate message with length 0.
AFAIK, as I wrote above, "no suitable client certificate" is in my opinion indicated by an empty list, means the certificate message has 3 bytes, all 0.

Openssl sends a Certificate message with length 0. AFAIK, as I wrote above, "no suitable client certificate" is in my opinion indicated by an empty list, means the certificate message has 3 bytes, all 0.

You're right, I focused on the server certificate message case, but neglected the client case, will push an updated version shortly...

I fixed the client side, now with no client-side keypair configured, it sends a zero-length "list".

The client works now also without a client's certificate together with Eclipse/Californium.

The server works now also without a client's certificate together with Eclipse/Californium ;-).
(From my side I finished interoperation tests for now. Once this PR gets closer to being merged, I will retest it and add also tests with tinydtls)

@tmshort I hope you don't mind the temporary "fork".  The intent is not to take over in any sense, rather this is a form of "active" review, by testing as well as reading the code. I think this deeper approach makes sense, this is a complex feature to review just by reading the code.
At this point, my "fork" has served its purpose, please feel free to adopt the top two commits (I don't even need attribution, they're actually trivial in the grand scheme of things) from the rpk-fixup branch of: https://github.com/vdukhovni/openssl.
The most substantive change is in tls_process_rpk() where there are a few ways to fine-tune the control flow, if you find some other equivalent form more suitable, feel free to reformulate accordingly.
The 2nd commit arranges for validation to not produce X509_V_OK in the absence of any actual validation criteria, the default state is untrusted.

@tmshort I hope you don't mind the temporary "fork". The intent is not to take over in any sense, rather this is a form of "active" review, by testing as well as reading the code. I think this deeper approach makes sense, this is a complex feature to review just by reading the code.

Thanks, I'll take a look.

Many thanks. Modulo final documentation review for nits/clarity etc., this is almost done. I do however want to tweak the RPK code a bit more, to allow empty client RPK (clients can respond with an "empty" (just length == 0) certificate message when they don't have anything to send, and this includes the RPK case and even with TLS 1.3 (after stuttering the request context).  The code for that is in: https://github.com/vdukhovni/openssl/pull/new/rpk-fixup2 (just one commit).
I'd also like to request one more round of (especially TLS 1.3) interop tests from @boaks.

Do please note the latest commit id in rpk-fixup2. Had to fix a couple of nits in the first draft...

@tmshort, by the way, thanks for persisting with a careful reading of the differences between the RPK certificate message encoding between TLS 1.3 and TLS 1.2. Modulo allowing an empty client certificate list (when the client has neither a cert nor RPK to send, and yet perversely, but legally, chose to advertise RPK support), your most recent version looks pretty good. My new "fork" just adds back support for empty client responses. Please review with care. This is the most delicate piece of the puzzle.

I'd also like to request one more round of (especially TLS 1.3) interop tests from @boaks.

Eclipse/Californium has only a DTLS 1.2 implementation. So no TLS not DTLS 1.3.
I will retest it on Monday.

I'd also like to request one more round of (especially TLS 1.3) interop tests from @boaks.

Eclipse/Californium has only a DTLS 1.2 implementation. So no TLS not DTLS 1.3. I will retest it on Monday.

Thanks. That should be largely the same for the core issues. It occurs to me that while empty RPK lists are fine with TLS 1.3, my overloading of 0-length for the actual RPK to mean no RPK in TLS 1.2 is likely ambitious.  I've send a message to the TLS WG, I hope it will attract some useful comments...
The cautious thing would be to tolerate 0-length RPKs in (D)TLS 1.2 servers, but not send them in (D)TLS 1.2 clients.
Otherwise, we need clear warnings to client implementors to not offer client RPKs if they don't have keys to offer, and servers should only solicit client-side RPKs if client auth is mandatory (since opting out interoperably may not be possible for clients with TLS 1.2 + RPK).

As I answered in the list, RFC5246, 7.4.6 Client Certificate  defines:
"If no suitable certificate is available, the client MUST send a
certificate message containing no certificates. That is, the certificate_list structure has a length of zero."
Covers for me RFC7250 as well. That section doesn't say something about
the certificate type and so in my interpretation it applies general
to all certificate types, including RPK.
Even if RPK is negotiated for the client, the client complies
to RFC5246, 7.4.6 sending a empty list in order to indicate,
that "no suitable certificate is available".

When if RPK is negotiated for the client, the client complies
to RFC5246, 7.4.6 sending a empty list in order to indicate,
that "no suitable certificate is available".

The problem is: there is no list. :-( We'll see whether any of the TLS protocol experts comment on the thread. I'll try and reach out to Paul Wouters...

The problem is: there is no list.

There is even "no suitable certificate is available" and then the MUST in RFC5246 is clear.
And yes, the empty list is no RPK certificate, but that doesn't really matter,
It's the MUST for "no suitable certificate".
I agree, that this requires the awareness of the tls-mailing-list. See, what we get there.

I pulled in some of @vdukhovni's changes, but I added a new flag to extensions for "raw public keys" in certificate messages. This simplifies some things by skipping CT and OCSP extensions, and permits new extensions to support X.509 and/or RPK in certificate messages. I thought this was cleaner than #ifdefing out code that would need to be brought in later.

Initial impression: This is basically done, modulo nits. Now just careful final review and polish.
Do you have test cases that ensure, in the absence of TLSA records, that the peer is "untrusted"? That wasn't the case originally, and should be added if not already done.  Otherwise, I believe this is feature complete.

Do you have test cases that ensure, in the absence of TLSA records, that the peer is "untrusted"? That wasn't the case originally, and should be added if not already done. Otherwise, I believe this is feature complete.

I will check and add additional test cases as necessary.

I've tested the interoperability with Eclipse/Californium and commit 2a68ff13ffc95b4a9e27f82f9161ac25844482ad.
"Works on my machine".

@vdukhovni, I made the TLSA match changes, but I reverted the changes that made the DANETLS definitions public. Now that they are no longer used by the public-facing API, there's no need for me to make them public.
Also, this has been squashed down to a single commit.

Yup, there's a conflict. I keep tabs on this, and rebase as needed.

I'm wondering how well the RPK support interacts with the recent additions by @baentsch for pluggable signatures. Can we have an RPK for a plugged signature alg?

Can we have an RPK for a plugged signature alg?

I don't know RFC7250, but from a quick cross-read there's nothing obvious as to why this should not work. Testing should be possible by way of driving the test tlsprovider, along the lines at
https://github.com/openssl/openssl/blob/931369429564b5a9bb09711de8e885fef546a0ac/test/sslapitest.c#L9562-L9597
within the new "rpktest.c".

I can't think of any reason why provider-based TLS signature algorithm would care about whether the wire certificate messages used RPKs or certificates. The only question is whether the provider signature algorithm can be configured by providing just the private key, or whether a certificate needs to be loaded as well. Does the initialisation of pluggable signatures require the caller to provide an X.509 certificate?

AFAIK, there are two kinds of such signatures, one is used for the x509 chains the other one for the handshake messages. The x509 signatures don't apply for RPK (RFC 7250). The handshake message signatures are applied for several handshake messages and are contained in the ServerKeyExchange and the CertificateVerify. These signatures are not related to x509:
I can't see any issue, which will cause the usage to fail.

The only question is whether the provider signature algorithm can be configured by providing just the private key, or whether a certificate needs to be loaded as well.

Providers don't know the concept of certificates, just that of public and private keys (and possibly their parameters) that can be (and are) created, queried, operated and stored by the OpenSSL logic as required, e.g., for TLS operation or creation of X.509 structures.

Does the initialisation of pluggable signatures require the caller to provide an X.509 certificate?

By default, the answer is No, but it might change if your definition of initialization and caller is different from what is spec'd.

I added RPK into sslapitest.c for the pluggable signatures test. It was easier than adding pluggable signatures into the RPK tests...

And now, @mattcaswell, I added a TLSProxy test!

Looks like a rebase is also needed

This pull request is ready to merge

Merged to master. Thank you all for your efforts in getting this in!

Thanks @tmshort for your work on this!

Yes, very much appreciated, especially for being willing to adapt the design to benefit from and in turn enrich the existing DANE support.
Thanks also to @mattcaswell for the timely review.


debug/dwarf: 0-length array problem

I'm attempting to wrap libusb so I can interface with my kinect.  I have basic control
working and have written the bulk and interrupt code, but isochronous requires using the
asynchronous API, which cgo seems to be having trouble with.

Consider the following code:

/* iso.go */
package usb

// #include <libusb-1.0/libusb.h>
import "C"

type Transfer C.struct_libusb_transfer
/* end */

The struct is documented here:
http://libusb.sourceforge.net/api-1.0/structlibusb__transfer.html

and defined here (see line 765):
http://libusb.sourceforge.net/api-1.0/libusb_8h_source.html

notably:
{...
struct libusb_iso_packet_descriptor iso_packet_desc[0];
...}

and cgo reports:
iso.go:7:15: struct size calculation error off=72 bytesize=64

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM
build 2335.15.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ go version
go version go1

$ go env
GOROOT="/opt/go"
GOBIN=""
GOARCH="amd64"
GOCHAR="6"
GOOS="darwin"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOTOOLDIR="/opt/go/pkg/tool/darwin_amd64"
GOGCCFLAGS="-g -O2 -fPIC -m64 -pthread -fno-common"
CGO_ENABLED="1"

Is this still a problem?  I can't get the test case in comment 4 to reproduce with any combination of Go version or compiler.  I don't see any other complete test cases here.
If this is still a problem, we need instructions on how to reproduce it.  Thanks.

Just tested with latest 1.9.2. No issues seen. Can this be an artifact of older Go versions ?


Add prebuilt binaries to readme.md

Link to prebuilt binaries should be available in readme.md for users who don't have Go installed and just want things to work.
Btw, this project works so well. Thanks for the hard work.

They are already attached to the releases :-)

Agreed, thanks for the contribution :-)


jQuery as a Dependency

I'm almost through with recoding cms.js to not rely on jQuery. Would that be something that I could attempt to merge, or should I keep that one on my own branch?
The main reason I ask is that some of my code replacements relies on ES6 which is fully supported in current browsers but is relatively new and may not work in older browsers.
I did already merge one piece of code for that which is a new way to do for: 'for (this of that)'.
Anyway, it's significant enough that I also wanted to get some opinions as I know while there would be advantages to not requiring jQuery that there may be reasons people want it to stay.

Thanks @barryanders I'm definitely open to using vanilla JS and was thinking of converting it down the line myself. Although, I would really like to keep support for ES5 though being that CMS.js is in the early stages of development/usage...at least for now until the ES6 gap is tightened.

+1 to remove jQuery as a dependency

In progress: #42

Looking through old issues and I noticed that #42 was closed, which was in part the same issue as this. If someone else wants to carry this on, feel free to start a new issue. I think cms.js is really cool and may make a nice smooth framework for non blog situations too (ex. electron apps). The remaining pieces that rely on jQuery are pretty heavily coded in from what I remember. It would require a lot to completely remove jQuery. In the spirit of closing old issues that are no longer being considered, I'm going to close this to clean up my list of open issues.


Extend int-pair literal range

Remove the (unnecessary) restriction to the first 250 bytes of the code-page and up the base used from 250 to 256. New range will be [-32767, -100] and [1001, 33868] (minimal negative at ⁽°d, maximal negative at ⁽””, minimal positive at ⁽¡¡, maximal positive at ⁽°c). Note: not backwardly compatible, but does cover the old range so any existing Jelly code may be ported.

I don't really want to make backwards-incompatible changes. Maybe there's something else we can do with the remaining 3036 combinations?

@DennisMitchell I suggest putting the 3036 extra integers in those.


Implement Sentiment Analysis service API

As a backend developer
I need to implement a sentiment analysis API
So that user feedback can be automatically categorized and analyzed for sentiment
Details and Assumptions
* The API will utilize natural language processing tools.

Acceptance Criteria
Given user feedback in text form
When the text is processed
Then the sentiment (positive, neutral, negative) is determined and recorded

Done


Rename ClassDB::class_call_static_method -> class_call_static

Small change as discussed in https://github.com/godotengine/godot/pull/93141#issuecomment-2442825542. The shorter name class_call_static is more consistent with Object::call and makes future extensibility (different call variants) easier.
Not breaking because the method was only introduced in the 4.4 cycle.

Thanks!


Audio cannot be shared

The audio of the system cannot be shared during screen sharing. Currently, only the audio of the microphone can be shared. How should I solve it?

I'm assuming you are talking about JS SDK. It can indeed be shared, but only for certain browsers. please refer to MDN docs on this topic

I'm assuming you are talking about JS SDK. It can indeed be shared, but only for certain browsers. please refer to MDN docs on this topic

    if (WebRTC.platformIsDesktop) {
      try {
        final source = await showDialog<DesktopCapturerSource>(
          context: context,
          builder: (context) => ScreenSelectDialog(),
        );
        if (source == null) {
          print('cancelled screenshare');
          return;
        }
        print('DesktopCapturerSource: ${source.id}');
        var track = await LocalVideoTrack.createScreenShareTracksWithAudio(
          ScreenShareCaptureOptions(
            captureScreenAudio: true,
            sourceId: source.id,
            maxFrameRate: 15.0,
          ),
        );
        await participant.publishVideoTrack(track[0] as LocalVideoTrack);
        await participant.publishAudioTrack(track[1] as LocalAudioTrack);
      } catch (e) {
        print('could not publish video: $e');
      }
      return;
    }
    if (WebRTC.platformIsAndroid) {
      // Android specific
      try {
        // Required for android screenshare.
        const androidConfig = FlutterBackgroundAndroidConfig(
          notificationTitle: 'Screen Sharing',
          notificationText: 'LiveKit Example is sharing the screen.',
          notificationImportance: AndroidNotificationImportance.Default,
          notificationIcon:
              AndroidResource(name: 'livekit_ic_launcher', defType: 'mipmap'),
        );
        await FlutterBackground.initialize(androidConfig: androidConfig);
        await FlutterBackground.enableBackgroundExecution();
      } catch (e) {
        print('could not publish video: $e');
      }
    }
    if (WebRTC.platformIsIOS) {
      var track = await LocalVideoTrack.createScreenShareTrack(
        const ScreenShareCaptureOptions(
          useiOSBroadcastExtension: true,
          maxFrameRate: 15.0,
        ),
      );
      await participant.publishVideoTrack(track);
      return;
    }
    await participant.setScreenShareEnabled(true, captureScreenAudio: true);
  }

    ScreenShareCaptureOptions? options,
  ]) async {
    options ??= const ScreenShareCaptureOptions(captureScreenAudio: true);

    final stream = await LocalTrack.createStream(options);

    List<LocalTrack> tracks = [
      LocalVideoTrack._(
        Track.screenShareName,
        TrackSource.screenShareVideo,
        stream,
        stream.getVideoTracks().first,
        options,
      )
    ];

    if (stream.getAudioTracks().isNotEmpty) {
      tracks.add(LocalAudioTrack(
          Track.screenShareName,
          TrackSource.screenShareAudio,
          stream,
          stream.getAudioTracks().first,
          const AudioCaptureOptions()));
    }
    return tracks;
  }

Hello, I am testing the flutter demo (https://github.com/livekit/client-sdk-flutter.git), when the audio is set to true, I still cannot get the system ### sound

Did you read the doc I linked to? Which browser/OS are you using and what are you trying to share?


JSON_EXISTS seems absent

Hi,
Somehow, I'm not able to find class for json_exists function - https://mariadb.com/kb/en/library/json_exists/.
How can we use that?
Please guide,
Hiren

fixed in master, thanx to @aalwash


merge

added razor peptides, total # peptides to protein output file

Coverage decreased (-0.6%) to 80.088% when pulling ff239c827373eaccede441e7460fea5eaa219298 on rmillikin:master into f6164f1f5505d3f9f64d76301e4d7cf287f2dd31 on smith-chem-wisc:master.


fix(smokeTest): Add label tests

Update smoke tests and add label tests to smoke tests

@jarifibrahim fabric8/fabric8-ui:SNAPSHOT-PR-2330-1 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2330-fabric8-planner.badger.fabric8.io

@jarifibrahim fabric8/fabric8-ui:SNAPSHOT-PR-2330-2 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2330-fabric8-planner.badger.fabric8.io


Support int16 images

I was looking at the docs and noted that the Image classes all seemed to relate to using PIL (which does not support multichannel int16 or float images). I'd like to suggest that this library handle multi-channel images with int16 type. This is an issue across higher level frameworks (see https://github.com/facebookresearch/detectron2/issues/698) and makes it harder for users that work with imagery that has to be in int16 data type. For example, most satellite imagery comes in either int16 or as a float type and satellite imagery is increasingly being used with the methods available in fastaiv2.

You can define your own image types that handles this in fastai v2 (see the medical module for instance). Adding support ourselves is not a priority at the moment, but you can see on the forum if others have already begun implementing such types already and share your code.


Sharing a workspace between multiple monitors?

I like this window manager, but it seems like workspaces are limited to only one monitor each. When I move a window near the edge of one monitor, it will not move to the next; as if there is a border preventing me. Is there a way to fix this or is it an intended feature? I'm assuming it might have something to do with the window manager source code being small and just not having as much stuff implemented (hence, byte-sized), but I was just curious and I thought maybe that's the reason why.
Thanks!

Nevermind, I fixed it. I had to set EDGE_LOCK in config.h.in to false. I'm aware it says not to edit those values, but I couldn't find an option to configure it with berryc and it happened to work out anyway.

It should be a berryc option: https://github.com/JLErvin/berry/blob/c66590292dcd41ca2d9f8083d717093cff97eb15/client.c#L78
we might need to add it to the man page, however.

Oh okay, thanks. Yeah I didn't see it in neither the manpage nor your website, but I did see the option in the config.h.in file. I didn't think to look in client.c though. I'll set it that way via berryc then :)


Can't make it work - SSMS 10.50.2500.0

I followed the instructions exactly, but I cannot get the plugin to show up in SSMS.  I put it in 'C:\ProgramData\TsqlFlex', in 'C:\ProgramData\Red Gate\T-SQL Flex', in 'C:\Program Files\Red Gate\TSQL Flex', and in 'C:\Program Files (x86)\Red Gate\TSQL Flex' all with no luck.
Does Alpha 11 not work with SQL Server 2008R2 / SSMS 10.50.2500.0?
Note: Release Alpha 10 works fine.
Here's my environment:
Windows 7 x64 w/SP1
SQL Server 2008 R2
SSMS - 10.50.2500.0

Hi there.  Alpha 11 should work great with that setup - in fact that's what I use at work.  Are you seeing the other items in the button bar that that come with the SIP framework?
Alpha 11 is the first version to have a Chocolatey package - have you ever used that?
https://chocolatey.org/
Once you get Chocolatey installed, the command-line to install T-SQL Flex is:
choco install tsqlflex -pre
The Chocolatey installer will also install the SIP framework prerequisite.

@razdyn I updated the install docs for Chocolatey.  Please try that and let me know if you can't get it working.
https://github.com/nycdotnet/TSqlFlex/blob/master/InstallationInstructions.md

Hi,
I have same issue than @razdyn. I tried to install TSQL manually and from chocolatey but T-SQL Flex button does not appear anymore :-(
Here is informations from my SSMS :
Microsoft SQL Server Management Studio						10.50.1600.1
Microsoft Data Access Components (MDAC)						6.3.9600.17415
Microsoft MSXML						3.0 4.0 6.0
Microsoft Internet Explorer						9.11.9600.17690
Microsoft .NET Framework						2.0.50727.8009
Operating Sytem						6.3.9600
.net framework installed on my computer is .net 4.5.1 but SSMS says that .net 2.0 is used. Is the issue due to that ?
Regards

@cooxkie  - it was working before but isn't now?  Where did you read that SSMS is using .NET 2.0?

Oy!  You're right.  I just loaded SSMS 2008 and T-SQL Flex is now not appearing.  I use SSMS 2014 usually.  How annoying!  I will look into this.  So sorry for the trouble.  Thanks for reporting.

You're welcome ;-) I hope you will find a solution, your plugin will be very usefull for me !

Red Gate has indicated that this is a known issue, but is workaround-able.  Apparently their SQL Scripts add-in is .NET 4.0 except for the loader that is .NET 3.5 so it works with SSMS 2008.  I'm disappointed that I missed this considering @mauvo took the trouble to explain it to me in detail.

I'm sorry but I'm not sure to understand what you mean ... is it working on SSMS 2008 or not ;-) ?

@cooxkie It should work if @nycdotnet recompiles for .Net 3.5. Which could be a pain if he's used some new language features or incompatible Nuget packages. An alternative is hosting his application in a separate process using named pipes or maybe MAF. SQL Scripts works this way, but it involved a lot of boilerplate.
Good luck Steve, hopefully the simple fix works... :-)

@cooxkie  It doesn't, but I intend to fix it ASAP.  For now, it should work in newer SSMS (like 2012 or higher) which still lets you connect to SQL Server 2008 and earlier databases.  I should have caught this when I initially converted the app.  If I can't get the workaround working, I'll revert to .NET 3.5 and just live with it.
@mauvo Thanks for the reply.  Yeah I specifically did upgrade it to use .NET 4 stuff.  Any chance you'd be willing to indulge my question on the SSMS-addin Google group?

@mauvo and @nycdotnet : Thanks it's clear now ;-)
@nycdotnet I'm waiting for your new package (in .net 3.5)
In my side, I will try to install SSMS 2012 but some of my client still to use SSMS 2005 ... so gap will be huge ;-) !

I am not actually using any new .NET 4 features (yet), so I should technically be able to downgrade it without much trouble.  I'm in the middle of a big project at the moment so it might be a week or two before I can get to it.

It's ok, I don't need it for the moment : I have already written my INSERT statement manually ;-) !
but it will be useful for the next time !

OK.  In the meantime as @razdyn identified, you can use alpha 10 which is available via the releases page.  https://github.com/nycdotnet/TSqlFlex/releases

yes, you're right ! it works fine !

This should be fixed in beta 1 which I've just released.  Thanks for your patience.


validation_step should be called when trainer.global_step % val_check_interval == 0

🐛 Bug

To Reproduce
Please take a look at the code sample.

Code sample

import os

import torch
from torch.nn import functional as F
from torch.utils.data import DataLoader
from torchvision.datasets import MNIST
from torchvision import transforms
import pytorch_lightning as pl

class MNISTModel(pl.LightningModule):

    def __init__(self):
        super(MNISTModel, self).__init__()
        self.l1 = torch.nn.Linear(28 * 28, 10)

    def forward(self, x):
        return torch.relu(self.l1(x.view(x.size(0), -1)))

    def training_step(self, batch, batch_nb, using_native_amp=False):
        print("At training_step, global_step=", self.global_step)
        x, y = batch
        loss = F.cross_entropy(self(x), y)
        tensorboard_logs = {'train_loss': loss}
        return {'loss': loss, 'log': tensorboard_logs}

    def validation_step(self, batch, batch_nb):
        print("At validation_step, global_step=", self.global_step)
        x, y = batch
        loss = F.cross_entropy(self(x), y)
        tensorboard_logs = {'val_loss': loss}
        return {'loss': loss, 'log': tensorboard_logs}

    def configure_optimizers(self):
        return torch.optim.Adam(self.parameters(), lr=0.02)

train_loader = DataLoader(MNIST(os.getcwd(), train=True, download=True, transform=transforms.ToTensor()), batch_size=32)
validation_loader = DataLoader(MNIST(os.getcwd(), train=False, download=True, transform=transforms.ToTensor()), batch_size=32)

mnist_model = MNISTModel()
trainer = pl.Trainer(gpus=-1,
                     limit_val_batches=1,
                     val_check_interval=10,
                     progress_bar_refresh_rate=0
                     )
trainer.fit(mnist_model, train_loader, validation_loader)

Expected behavior

I set the val_log_interval=10. validation_step is called two times at global_step=0 because of the sanity check and then called again at global_step=9, 19, 29... I think it makes more sense if it is called at global_step=10, 20, 30...
At validation_step, global_step= 0
At validation_step, global_step= 0
At training_step, global_step= 0
At training_step, global_step= 1
At training_step, global_step= 2
At training_step, global_step= 3
At training_step, global_step= 4
At training_step, global_step= 5
At training_step, global_step= 6
At training_step, global_step= 7
At training_step, global_step= 8
At training_step, global_step= 9
At validation_step, global_step= 9
At training_step, global_step= 10
At training_step, global_step= 11
At training_step, global_step= 12
At training_step, global_step= 13
At training_step, global_step= 14
At training_step, global_step= 15
At training_step, global_step= 16
At training_step, global_step= 17
At training_step, global_step= 18
At training_step, global_step= 19
At validation_step, global_step= 19
At training_step, global_step= 20
At training_step, global_step= 21
At training_step, global_step= 22
At training_step, global_step= 23

Environment

CUDA:
- GPU:
- Tesla T4
- available:         True
- version:           10.2
Packages:
- numpy:             1.18.5
- pyTorch_debug:     False
- pyTorch_version:   1.6.0.dev20200622
- pytorch-lightning: 0.8.0
- tensorboard:       1.15.0
- tqdm:              4.46.1
System:
- OS:                Linux
- architecture:
- 64bit
-
- processor:         x86_64
- python:            3.7.7
- version:           #28~18.04.1-Ubuntu SMP Sat Jun 6 00:0

Additional context

global_step starts from 0, and since val_log is an interval, the current behavious looks fine to me.

looks fine to me. val_log_interval is just how often logs are sent to the logger, but it has no influence on global step which is always incrementing in training step.

Sorry I do not agree. The first validation step happens at 0, then 9, then 19. There are only 9 steps between 0 and 9 and 10 steps between 9 and 19.
Also, this val_check_interval is not consistent with row_log_interval. In the above case, if I set both of them to be 10, the logger will log training at step 0, 10, 20, 30,... and log validation at step 0 (two times because of sanity check), 9, 19, 29,... This creates inconsistency.

Is it correct if you set num_sanity_val_steps=0?

With num_sanity_val_steps=0, it still runs validation at 9, 19, 29,... as you mentioned earlier, validation runs after val_check_interval number of training steps.

Sorry I do not agree. The first validation step happens at 0, then 9, then 19. There are only 9 steps between 0 and 9 and 10 steps between 9 and 19.

0-9 -> 10 steps
then it will run for 10-19 -> 10 steps again
then it will run for 20-29 -> 10 steps again
...
...
Looks fine.

I understand that the current logic is validation happens every val_check_interval of training steps. I think it makes more sense if validation happens val_check_interval number of training steps after the last validation. If not, it will be inconsistent with row_log_interval. The training log and validation log is alway off by one step if I set val_check_interval and row_log_interval to be the same. So I think we could count the validation sanity check at step 0 to be a validation step so the validation happens at step 0, then 10, 20, 30. This provides users flexiblility (user can set num_sanity_val_steps=0 or 1) and aligns the training and validation logging.


python38Packages.zetup: fix build

Currently fails to build on python 3.8 due to an overly restrictive version bound.
ZHF: #80379
CC @NixOS/nixos-release-managers

Motivation for this change
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

@GrahamcOfBorg build python37Packages.zetup

Could you attach a build log from hydra with the failing build?
It would be helpful to do that with all ZHF PRs or for any build fix.

Sure, I'll start doing that.  Here's zetup on 20.03:
https://hydra.nixos.org/build/115539216

Or I guess this is the more useful URL to link, since it shows the repeated pattern of failures on release-20.03?
https://hydra.nixos.org/job/nixos/release-20.03/nixpkgs.python38Packages.zetup.x86_64-linux

Or I guess this is the more useful URL to link, since it shows the repeated pattern of failures on release-20.03?
https://hydra.nixos.org/job/nixos/release-20.03/nixpkgs.python38Packages.zetup.x86_64-linux

The build would be best, I don't think you can do permanent time ranges, and eventually that will advance into the future where you won't see that pattern anymore.


Bug in doCalendarAddACL

doCalendarAddACL() has a bug in the "except KeyError:" at line 1311 (GAM 3.42). This appears to be for picking up an exception when there's no 6th argv. However, sys.arg is a sequence, not a dictionary so the exception should be IndexError. The effect of the bug is that when attempting to use "domain" for add, update or delete, GAM fails with an error. Note that this is a separate bug to Issue 32.
The fix is to change line 1311 to
except IndexError:

fixed in master and will be included in next release:
https://github.com/jay0lee/GAM/commit/e37e6935c48fd42818a1b9e7bf8526f829183fcf


MGDOBR-676,677: Cover delete Processor and Instance

For more details see:

https://issues.redhat.com/browse/MGDOBR-676
https://issues.redhat.com/browse/MGDOBR-677

Sorry @jomarko I will not have time to review this before my PTO.
I have removed myself as a reviewer.

@sjamboro
Do you plan to add the assertation of:

the name validation (insert a wrong name of deleted instance)
the error messages (processors exist)

Not as part of this PR, please create a jira for me if you think such tests are needed. Especially insert wrong name of deleted instance - I believe it is feature of patternfly, that we shouldn't test.
@vpellegrino ? ^

@sjamboro
Do you plan to add the assertation of:

the name validation (insert a wrong name of deleted instance)
the error messages (processors exist)

Not as part of this PR, please create a jira for me if you think such tests are needed. Especially insert wrong name of deleted instance - I believe it is feature of patternfly, that we shouldn't test.
@vpellegrino ? ^

@jomarko I checked and it seems that the logic for delete confirmation is managed on our side (https://github.com/5733d9e2be6485d52ffa08870cabdee0/sandbox-ui/blob/4e3a4108fe496954f545d86ef3135975d92ea310/src/app/components/DeleteModal/DeleteModal.tsx#L57)
However, I agree to manage these tests in a separate task.


Request add endpoint to get user's verified state.

Feature: New Apiary Endpoint to request user information
Why is this feature being added?
Currently pybot provides new slack members with useful resources. per front end issue #765. Only members who are verified veterans are eligible for certain resources ex: mentorship, and veterans scholarships. We shouldn't offer these resources to individuals who don't qualify.
I'd like to be able to get an endpoint in which I can take a registered user information which is connected to a slack id to user information. Additionally there are other sections within the User Table that would be helpful if exposed (mentor, details about service, interests and contact information).
Since this is being requested by an external program some of these details might be important to keep secure. I'm unsure if the API is public facing or if we need to make a way for only registered applications/ requests to get the information.

Hey there, myself and @MiguelSilva1997 are first time contributors and would like to tackle this issue, is it still available?

Hi there, it's currently in progress as seen here:
https://github.com/OperationCode/operationcode_backend/pull/240
I'm new to ruby, and the current Project Lead has exciting personal things keeping him away from this project. If you'd like to look over what I've done you're more than welcome to add onto it.
The current things that are in progress are making the endpoint more secure than a global variable, I also need to include exception handling for the database access and any other good practices in ruby.

we'd love to talk more, is there a workspace we can join?

Hi yeah, come join us here: https://operationcode.org/signup

I want make sure you know you don't have to be a vet or related to vet, we have many members who just want to contribute and looking for an easy place to communicate.

@OperationCode/issues-team - Is this issue part of the current roadmap?  If so, can we layout exactly what pain point we are trying to resolve, and confirm that this is the best way to accomplish that.  Otherwise, I am not sure we want to expose the backend API in this manner.

@wimo7083 prolly best to describe some examples that pybot could run through provided it had eyes on user details.

In the PR I mentioned a few examples of things I would like to do: PR #240
The three primary reasons I see this as helpful.

I'd like to be able to get verified status from the backend to serve additional content, currently the slackbot is used to handle the mentor notification system. We currently have routes to get to the mentor request that don't require verification. I want to eliminate that, and make a simple interface for mentor request within slack.
For the longest time when people join slack we've offered a choice of resources. Currently it's this list:

When members join we ask them what they are interested in, and then ignore those items and tell them to look at ruby, python and whatever has been there for over a year. As we are trying to support all tech careers I'd like to use the information that people gave us and offer them resources.
Lastly, if someone joins slack it's not tied to the backend database. Part of this route that I'm setting up takes a verified user signup and connects the slack signup to the backend signup. In the future this means that we can politely send them an email that reminds people who don't sign up about our slack community.

To me, this request seems to solidly fall in line with our mission statement, and if we can come up with some kind of authentication solution we should be able to minimize the exposure of the backend api.

While I can certainly see the use of this feature, my main concern is whether this information will be exposed publicly.  Because there is personal information included in it - I would only be open to this if there were some sort of auth required to access the API.  This is not on our current road map (which will be released soon!) - I'd rather do the verification of whether someone is a veteran after they request the resource, rather than determining it before showing them the resources that are available.    That said, I am certainly open to other opinions on this.

Auth would be required, if you have any suggestions on my contribution I'll definitely take them.
I agree that any data should be kept private and subject to any security policy you state.
The veteran status was to help people in that awkward scenario in which they had to ask and deny services when someone didn't qualify.
Looking through the old Issues I also see that #37 lines up pretty well with this change. We currently notify members when people join. Getting the zipcode from backend and finding a community leader would be fairly easy and keep it all in slack.
Additionally there's already issues in frontend for a map that's going to require a similar endpoint for all user location and event location for all events.

I'll explore some authentication options to secure our API, for non-user consumers (i.e. Slack).

Thanks. If you give me the requirements. I can do the footwork.

Closing this out in favor of the Slack integration issues 1 - 6


How do I delete the created Account again?

I am not a fan of the fact that this used my loginname for wordpress as the user handle. I very much prefer Pterotypes approach to just use<EMAIL_ADDRESS>Now i deinstalled the plugin again, but i donÄt know how to delete the Account created on the Fediverse since I don't have access to it. How do I do that?
Thank you

I have chosen the username, because this supports multiple users per blog. What are your concerns using the username?
You have no account in the „fediverse“ it all works decentral. If you reinstall the plugin, your account is gone.

And, as far as I know pterotype also works this way...

i deleted both plugins. The Account created by pterotype (blog@my-domain) can't be find anymore. But the one created by Activitypub still shows up when I search for my domain on Mastadon. So it has to been entered into some registry or some part of the plugin does not deacitvate when you deinstall.

Ah, I see... This is a problem with mastodons caching system... 😞

Or it is, because pterotype also uses the username...

So it will disappear after a bit? I thought it had something to do with the plugin since I deinstalled both at the same time and the pterotype account vanished instantly.

I deinstalled pterotype as well

You can try it on webfinger.net
If you provide me your blog URL, I will have a look.

I would not mind if it was my Display name btw.  So it really seems a caching issue.

I would like an input field, where I would enter a name of my choice. Don't like it, to be forced to use WP username. Would that be possible?

Thank you for your time :)

@Suitbert because of any security reasons and/or other concerns or simply because of a "stupid" login name?
In the second case the easiest solution would be to change the login name: https://www.wpbeginner.com/wp-tutorials/how-to-change-your-wordpress-username/

@Suitbert but to answer you question: Sure it is possible.

Yes, would prefer not to use the WP username, because I do use different names for admin, editor etc. I do not want to show the names in public.

@Suitbert could it be based on pseudonym field?

I definitely like this approach; needs to support multiple authors. that's still an interesting spot. Only thing that would be even cooler, is if for instance, your site has a "site" account, say, on an instance you run, the plugin should allow you to pick the instance that it uses, if possible, rather than creating another account on the fediverrse. I'm having issues getting people to follow my blog, even though they follow my normal account and interact with it. So, there also needs to be a betterr form of discovery.

In the second case the easiest solution would be to change the login name: https://www.wpbeginner.com/wp-tutorials/how-to-change-your-wordpress-username/

I did so after I already had the plugin active and all that. And it doesn't find my new username in Mastodon. Finds it in Friendica but even tho I click follow, it cannot follow.
Original handle<EMAIL_ADDRESS>New one<EMAIL_ADDRESS>