text:
Three-item-per-row list output | 'openssl enc -ciphers'

OS: Fedora; Component: openssl.x86_64 1:1.1.1i-3.fc33
Hi. When items to be listed in output by a command-line tool, are all belonging to a same and unique class object, like it is the case with 'openssl enc -ciphers' with ciphers as class object, such items have been proven to be most efficiently listed as a one-item-per-row output, which provides the best possible starting state for post-processing the items. Then 'openssl list -cipher-algorithms', like so many others commands in UNIX/LINUX command-line tools, adheres to that principle. Though that principle was forgotten for a while when 'openssl enc -ciphers', a three-item-per-row list output, was conceived. Illustration, if needed, of the state a non-conventional listing output leads to.
$ openssl enc -ciphers | grep -E 'chacha|^-aes-256'
-aes-256-cfb               -aes-256-cfb1              -aes-256-cfb8
-aes-256-ctr               -aes-256-ecb               -aes-256-ofb
-chacha20                  -des                       -des-cbc

A command may grow as complex as the one that follows in order to match the previous command if it had observed the one-item-per-row list output principle.
$ openssl enc -ciphers | sed 1d | awk '{for(i=1;i<=NF;i++) printf "%s\n",$i}' | grep -E 'chacha|^-aes-256' | sed 's/^\-//' | sort -r | column
chacha20	aes-256-ecb	aes-256-cfb8	aes-256-cfb
aes-256-ofb	aes-256-ctr	aes-256-cfb1	aes-256-cbc

Otherwise, the pages of these links' URLs are redirected to a page served as HTTPS, https://www.openssl.org/; perhaps this link could be updated.
$ rpm -qi openssl | sed -n 16p
URL         : http://www.openssl.org/
$ dnf -q info openssl | sed -n 12p
URL         : http://www.openssl.org/

Most of this seems a fedora issue, but the "-1" option might be useful to you.
Arguably, "-1" should be the default "if !isatty(1)"

Hi! That "if !isatty(1)" was an unknown expression to me.  My investigation led me to the related man-page 'man 3 isatty' which reveals it not to be a function aimed to be executed in terminal.  The best candidate article i found to cover it was from https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/isatty.htm.

Most of this seems a fedora issue, but the "-1" option might be useful to you.

I do not think I see anything Fedora specific here.

The openssl enc -ciphers is basically deprecated so I do not think we should touch that output.
And you can use openssl list -1 -cipher-commands instead.
So the only remaining possible RFE would be to use the if (!isatty(STDOUT_FILENO)) to set the -1 option automatically.

That's a good information, "openssl enc -ciphers is basically deprecated". I had conceived that command could be the best candidate for listing supported ciphers, upon the recommendation "Depending on how OpenSSL was configured and built, not all ciphers listed here may be present. See enc(1) for more information and command usage" in manual openssl(1). Regards to if (!isatty(STDOUT_FILENO)) i would not know in what context it is aimed to be introduced.
Here Chacha is not part of the ciphers list. Maybe it is intended to be so.
$ openssl list -1 -cipher-commands | grep -iE 'chacha|aes' | column
aes-128-cbc	aes-192-cbc	aes-256-cbc
aes-128-ecb	aes-192-ecb	aes-256-ecb

Here Chacha is part of the ciphers list. Maybe it is intended to be so too.
$ openssl list -cipher-algorithms | grep -iE 'chacha|^aes-256'| column
AES-256-CBC		AES-256-CFB8		AES-256-XTS
AES-256-CBC-HMAC-SHA1	AES-256-CTR		ChaCha20
AES-256-CBC-HMAC-SHA256	AES-256-ECB		ChaCha20-Poly1305
AES-256-CFB		AES-256-OCB
AES-256-CFB1		AES-256-OFB

I think using isatty(3) in the list app would enable single-column output by default.  Compare ls with ls|cat

Marking as inactive, to be closed at the end of 3.4 dev barring further input

authors: Ricky-Tigg nhorman richsalz t8m

repo: openssl/openssl


text:
Windows 3.0.X build warning: lib naming for engines and ossl-modules

Hi,
Conitnuing https://github.com/openssl/openssl/issues/16984 that fix build issue on dll naming for Windows (validated on 3.0.5), it still remain a messy warning:
engines\capi.def(5) : warning LNK4093: Drive/Directory component ignored in 'LIBRARY' statement
   Creating library engines\capi.lib and object engines\capi.exp
Generating code
Finished generating code
e_dasync.c
engines\dasync.def(5) : warning LNK4093: Drive/Directory component ignored in 'LIBRARY' statement
   Creating library engines\dasync.lib and object engines\dasync.exp
Generating code
Finished generating code
pvkfmt.c
e_loader_attic.c
engines\loader_attic.def(5) : warning LNK4093: Drive/Directory component ignored in 'LIBRARY' statement
   Creating library engines\loader_attic.lib and object engines\loader_attic.exp
Generating code
Finished generating code
e_ossltest.c
engines\ossltest.def(5) : warning LNK4093: Drive/Directory component ignored in 'LIBRARY' statement
   Creating library engines\ossltest.lib and object engines\ossltest.exp
Generating code
Finished generating code
e_padlock.c
engines\padlock.def(5) : warning LNK4093: Drive/Directory component ignored in 'LIBRARY' statement
   Creating library engines\padlock.lib and object engines\padlock.exp
Generating code
Finished generating code
legacyprov.c

According to https://github.com/openssl/openssl/commit/e5f831a065df1d6e4640ef389f8594a5f10c9c8e#diff-adf3ecfda4c92bad70382334b4d8089beb88119774ee3447c7a718df0de29ceaL747 --name must be the canonical name of the lib without path.
Here is my dirty patch that fix it with a full & clean working build for Windows:
diff --git "a/Configurations/windows-makefile.tmpl" "b/Configurations/windows-makefile.tmpl"
index 47c10d79df..4c8370e0ed 100644
--- "a/Configurations/windows-makefile.tmpl"
+++ "b/Configurations/windows-makefile.tmpl"
@@ -743,6 +743,8 @@ EOF
           my $ord_ver = $args{intent} eq 'lib' ? ' --version $(VERSION_NUMBER)' : '';
           my $ord_name =
               $args{generator}->[1] || platform->dsoname($args{product});
+          my @arr=split /\\/,$ord_name;
+          my $ord_name=$arr[(scalar(@arr))-1];
           return <<"EOF";
 $target: $gen0 $deps $mkdef
 	"\$(PERL)" "$mkdef"$ord_ver --type $args{intent} --ordinals $gen0 --name $ord_name --OS windows > $target

Have a look at #18732

Hi @levitte,
Many Thx for the existing PR!
I confirm that https://github.com/openssl/openssl/pull/18732 fix it in a better way than my patch ;)

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
OPENSSL: Linux SLESS11 [rt.openssl.org #4702]

Migrated from rt.openssl.org#4702 (status was 'open')
Requestors:

jose.oliveira@grupoicts.com.br

From jose.oliveira@grupoicts.com.br on 2016-10-10 14:14:56:
Hi,
I have downloaded and builded last tree openssl versions for linux:
1)      openssl-1.0.1u.tar.gz
2)      openssl-1.0.2j.tar.gz
3)      openssl-1.1.0b.tar.gz

I successful followed all steps found at file INSTALL

By the way, when I try to use it I have the bellow messages:
   undefined reference to ÂEVP_CIPHER_CTX_initÂ
   undefined reference to ÂEVP_CIPHER_CTX_cleanupÂ

The OS IÂ´m using is a Linux SLESS11 desktop 32 bits: kernel
3.0.13-0.27-default

Regards,

JosÃ© Carlos de Oliveira (Oliveira)
Pesquisador / Desenvolvedor - Grupo ICTS
Brasilia - DF - Asa Norte
SCN Q05 - Brasilia Shopping - Torre Norte Sala 917
Fone:+5561-3246.7089
   Cel:+5561-99311.9226
  Site:  <http://www.grupoicts.com.br/> www.grupoicts.com.br

From matt@openssl.org on 2016-10-10 14:24:46:

On 10/10/16 15:14, Jose Carlos de Oliveira via RT wrote:
> Hi,
> I have downloaded and builded last tree openssl versions for linux:
> 1)      openssl-1.0.1u.tar.gz
> 2)      openssl-1.0.2j.tar.gz
> 3)      openssl-1.1.0b.tar.gz

Any particular reason why you need all three?

>
> I successful followed all steps found at file INSTALL
>
> By the way, when I try to use it I have the bellow messages:
>    undefined reference to ÂEVP_CIPHER_CTX_initÂ
>    undefined reference to ÂEVP_CIPHER_CTX_cleanupÂ

What was the exact command you issued to see the above?

EVP_CIPHER_CTX_cleanup() no longer exists in OpenSSL 1.1.0.
EVP_CIPHER_CTX_init() is just a macro for EVP_CIPHER_CTX_reset() in 1.1.0.

Matt

>
> The OS IÂ´m using is a Linux SLESS11 desktop 32 bits: kernel
> 3.0.13-0.27-default
>
> Regards,
>
>
> JosÃ© Carlos de Oliveira (Oliveira)
> Pesquisador / Desenvolvedor - Grupo ICTS
> Brasilia - DF - Asa Norte
> SCN Q05 - Brasilia Shopping - Torre Norte Sala 917
> Fone:+5561-3246.7089
>    Cel:+5561-99311.9226
>   Site:  <http://www.grupoicts.com.br/> www.grupoicts.com.br
>
>
>
>

From jose.oliveira@grupoicts.com.br on 2016-10-10 16:56:51:
Thank you!

JosÃ© Carlos de Oliveira (Oliveira)
Pesquisador / Desenvolvedor - Grupo ICTS
Brasilia - DF - Asa Norte
SCN Q05 - Brasilia Shopping - Torre Norte Sala 917
Fone:+5561-3246.7089
   Cel:+5561-99311.9226
  Site: www.grupoicts.com.br

-----Mensagem original-----
De: Matt Caswell via RT [mailto:rt@openssl.org]
Enviada em: segunda-feira, 10 de outubro de 2016 11:25
Para: jose.oliveira@grupoicts.com.br
Cc: openssl-dev@openssl.org
Assunto: Re: [openssl-dev] [openssl.org #4702] OPENSSL: Linux SLESS11

On 10/10/16 15:14, Jose Carlos de Oliveira via RT wrote:
> Hi,
> I have downloaded and builded last tree openssl versions for linux:
> 1)      openssl-1.0.1u.tar.gz
> 2)      openssl-1.0.2j.tar.gz
> 3)      openssl-1.1.0b.tar.gz

Any particular reason why you need all three?

>
> I successful followed all steps found at file INSTALL
>
> By the way, when I try to use it I have the bellow messages:
>    undefined reference to âEVP_CIPHER_CTX_initâ
>    undefined reference to âEVP_CIPHER_CTX_cleanupâ

What was the exact command you issued to see the above?

EVP_CIPHER_CTX_cleanup() no longer exists in OpenSSL 1.1.0.
EVP_CIPHER_CTX_init() is just a macro for EVP_CIPHER_CTX_reset() in 1.1.0.

Matt

>
> The OS IÂ´m using is a Linux SLESS11 desktop 32 bits: kernel
> 3.0.13-0.27-default
>
> Regards,
>
>
> JosÃ© Carlos de Oliveira (Oliveira)
> Pesquisador / Desenvolvedor - Grupo ICTS Brasilia - DF - Asa Norte SCN
> Q05 - Brasilia Shopping - Torre Norte Sala 917
> Fone:+5561-3246.7089
>    Cel:+5561-99311.9226
>   Site:  <http://www.grupoicts.com.br/> www.grupoicts.com.br
>
>
>
>

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4702
Please log in as guest with password guest if prompted

Issue appears to be resolved. Closing.

authors: mattcaswell richsalz


text:
segfaults with dlmopen

OpenSSL functions such as SHA1() make segfault when the dynamically linked functions are called before.

An example program to reproduce this issue.

----- d.c -----
#define _GNU_SOURCE
#include <string.h>
#include <stdio.h>
#include <dlfcn.h>
#include <assert.h>
#include <openssl/sha.h>

int
comp_sha1()
{
        unsigned char md[SHA_DIGEST_LENGTH];
        const unsigned char data[] = "abcdef";
        size_t size;
        int i;

        size = strlen((char *)data);
        printf("sha1 = %p\n", SHA1);
        SHA1(data, size, md);
        printf("sha1 done\n");
        for (i = 0; i < SHA_DIGEST_LENGTH; ++i)
                printf("%02x", md[i]);
        printf("\n");
        return (0);
}

int
main()
{
        unsigned char md[SHA_DIGEST_LENGTH];
        const unsigned char data[] = "abcdef";
        size_t size;
        int i;
        unsigned char (*sha1)(const unsigned char *data, size_t count, unsigned char *md_buf);

        void *h = dlmopen(LM_ID_NEWLM, "libcrypto.so", RTLD_NOW);
        sha1 = dlsym(h, "SHA1");
        dlclose(h);
        assert(sha1);

        size = strlen((char *)data);
        printf("sha1 (dlmopen) = %p\n", sha1);
        sha1(data, size, md);
        printf("sha1 (dlmopen) done\n");
        for (i = 0; i < SHA_DIGEST_LENGTH; ++i)
                printf("%02x", md[i]);
        printf("\n");

        comp_sha1();

        return (0);
}

How to reproduce

$ cc d.c -lcrypto
$ ./a.out
sha1 (dlmopen) = 0x7f4b85ae40f0
sha1 (dlmopen) done
1f8ac10f23c5b5bc1167bda84b833e5c057a77d2
sha1 = 0x7f4b8620c0f0
sha1 done
1f8ac10f23c5b5bc1167bda84b833e5c057a77d2
Segmentation fault (core dumped)
We are using ubuntu 24.04 and libssl 3.0.13-0ubuntu3.4 amd64
Regards,
Osamu

#define _GNU_SOURCE
#include <string.h>
#include <stdio.h>
#include <dlfcn.h>
#include <assert.h>
#include <openssl/sha.h>

// Function to compute SHA-384 hash using the statically linked OpenSSL library
int comp_sha384() {
    unsigned char md[SHA384_DIGEST_LENGTH];
    const unsigned char data[] = "abcdef";
    size_t size;
    int i;

    // Calculate the size of the data
    size = strlen((char *)data);
    // Print the address of the SHA384 function
    printf("sha384 = %p\n", SHA384);
    // Compute the SHA-384 hash
    SHA384(data, size, md);
    printf("sha384 done\n");
    // Print the hash in hexadecimal format
    for (i = 0; i < SHA384_DIGEST_LENGTH; ++i)
        printf("%02x", md[i]);
    printf("\n");
    return 0;
}

int main() {
    unsigned char md[SHA384_DIGEST_LENGTH];
    const unsigned char data[] = "abcdef";
    size_t size;
    int i;
    // Function pointer for the SHA384 function
    unsigned char* (*sha384)(const unsigned char *data, size_t count, unsigned char *md_buf);

    // Load the libcrypto.so library dynamically into a new namespace
    void *h = dlmopen(LM_ID_NEWLM, "libcrypto.so", RTLD_NOW);
    // Get the address of the SHA384 function from the dynamically loaded library
    sha384 = dlsym(h, "SHA384");
    // Close the dynamically loaded library
    dlclose(h);
    // Ensure the function pointer is valid
    assert(sha384);

    // Calculate the size of the data
    size = strlen((char *)data);
    // Print the address of the dynamically loaded SHA384 function
    printf("sha384 (dlmopen) = %p\n", sha384);
    // Compute the SHA-384 hash using the dynamically loaded SHA384 function
    sha384(data, size, md);
    printf("sha384 (dlmopen) done\n");
    // Print the hash in hexadecimal format
    for (i = 0; i < SHA384_DIGEST_LENGTH; ++i)
        printf("%02x", md[i]);
    printf("\n");

    // Call the function that uses the statically linked SHA384 function
    comp_sha384();

    return 0;
}

use sha384 here instead.

Thanks, but it doesn't work for me.
$ ./a.out
sha384 (dlmopen) = 0x7f43891d7210
sha384 (dlmopen) done
c6a4c65b227e7387b9c3e839d44869c4cfca3ef583dea64117859b808c1e3d8ae689e1e314eeef52a6ffe22681aa11f5
sha384 = 0x7f43898ff210
sha384 done
c6a4c65b227e7387b9c3e839d44869c4cfca3ef583dea64117859b808c1e3d8ae689e1e314eeef52a6ffe22681aa11f5
Segmentation fault (core dumped)

it is a two way hash

dynamic

#define _GNU_SOURCE
#include <string.h>
#include <stdio.h>
#include <dlfcn.h>
#include <assert.h>
#include <openssl/sha.h>

// Function to compute SHA-384 hash using the statically linked OpenSSL library
void compute_sha384(const unsigned char *data) {
    unsigned char md[SHA384_DIGEST_LENGTH];
    size_t size = strlen((char *)data);
    int i;

    // Compute the SHA-384 hash
    SHA384(data, size, md);
    printf("SHA-384 hash: ");
    // Print the hash in hexadecimal format
    for (i = 0; i < SHA384_DIGEST_LENGTH; ++i)
        printf("%02x", md[i]);
    printf("\n");
}

int main() {
    const unsigned char data[] = "abcdef";

    // Call the function to compute the SHA-384 hash
    compute_sha384(data);

    return 0;
}

Tell me if it works.

The problem is occuring because you are attempting to use two copies of libcrypto, each of which registers an atexit handler for the application, which is bad.  Because you are using two copies of the library (one implicitly linked to the application, reachable via SAH384, and the other reachable via the dlmopened handle), each registers a copy of the OPENSSL_cleanup atexit handler.  When the application exits, the first cleanup call runs without issue, but the second attempts to cleanup data which has already been deregistered, leading to a segfault on program exit.
this code works properly:
#define _GNU_SOURCE
#include <string.h>
#include <stdio.h>
#include <dlfcn.h>
#include <assert.h>
#include <openssl/crypto.h>
#include <openssl/sha.h>

// Function to compute SHA-384 hash using the statically linked OpenSSL library
int comp_sha384() {
    unsigned char md[SHA384_DIGEST_LENGTH];
    const unsigned char data[] = "abcdef";
    size_t size;
    int i;

    // Calculate the size of the data
    size = strlen((char *)data);
    // Print the address of the SHA384 function
    printf("sha384 = %p\n", SHA384);
    // Compute the SHA-384 hash
    SHA384(data, size, md);
    printf("sha384 done\n");
    // Print the hash in hexadecimal format
    for (i = 0; i < SHA384_DIGEST_LENGTH; ++i)
        printf("%02x", md[i]);
    printf("\n");
    return 0;
}

int main() {
    unsigned char md[SHA384_DIGEST_LENGTH];
    const unsigned char data[] = "abcdef";
    size_t size;
    int i;
    // Function pointer for the SHA384 function
    unsigned char* (*sha384)(const unsigned char *data, size_t count, unsigned char *md_buf);
    int (*initcrypto)(uint64_t opts, const OPENSSL_INIT_SETTINGS *settings);

    // Load the libcrypto.so library dynamically into a new namespace
    void *h = dlmopen(LM_ID_NEWLM, "libcrypto.so", RTLD_NOW);
    // Get the address of the SHA384 function from the dynamically loaded library
    sha384 = dlsym(h, "SHA384");
    initcrypto = dlsym(h, "OPENSSL_init_crypto");

    initcrypto(OPENSSL_INIT_NO_ATEXIT, NULL); //DONT REGISTER AN ATEXIT HANDLER FOR THIS LIB COPY
    // Ensure the function pointer is valid
    assert(sha384);

    // Calculate the size of the data
    size = strlen((char *)data);
    // Print the address of the dynamically loaded SHA384 function
    printf("sha384 (dlmopen) = %p\n", sha384);
    // Compute the SHA-384 hash using the dynamically loaded SHA384 function
    sha384(data, size, md);
    printf("sha384 (dlmopen) done\n");
    // Close the dynamically loaded library
    dlclose(h);
    // Print the hash in hexadecimal format
    for (i = 0; i < SHA384_DIGEST_LENGTH; ++i)
        printf("%02x", md[i]);
    printf("\n");

    // Call the function that uses the statically linked SHA384 function
    comp_sha384();

    return 0;
}

authors: fochoao-alt nhorman otatebe


text:
DOC: document in more detail what a BIO_read_ex() via BIO_f_buffer() does

The BIO_f_buffer() documentation tells in enough detail how it affects
BIO_gets(), but not how it affects BIO_read_ex().  This change
remedies that.
Fixes #10859

This is an alternative to #10876

Ping!

Ping!

source: gharchive/pull-request


text:
doc: fix trace category names

The ENGINE_CONF and PROVIDER_CONF trace categories were merged
into a single CONF category (see bc362b9b7202 and 71849dff56d6).
Checklist

[x] documentation is added or updated

ping

Uhm...  why?  What if I only want to trace provider configurations?

Uhm... why? What if I only want to trace provider configurations?

That's a question you need to ask yourself  (see bc362b9 and 71849df). I only changed the documentation to match the facts. ;-)

What, you want me to be consistent?  :laughing:
Ah well, I can't argue against myself, better things to do...  carry on :wink:

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Merged to master as e978ab7894e966579fcd372d7cba9e051ba90150, thanks!

authors: levitte mspncp openssl-machine


text:
Allow lack of psk_key_exchange_modes for TLS < 1.3

Fixes #15375

Checklist

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

As the issue is not a bug, closing.

Let me reopen the PR as @t8m reopened the original bug report

Yes, but is this the right fix?

Well. Not sure really, but it at least restores the previous behavior for TLS < 1.3

This should be closed again as the missing alert that was the reason for reopening the original issue was added.


text:
ssl: do not choose auto DH groups that are weaker than the security level

Manual merge of #15818 to 1.1.1.

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

Test issues.

The test failure is related to SSLv3 and key sizes.

Reviewable now.

This pull request is ready to merge

Merged.

authors: openssl-machine paulidale


text:
s_client: Better response success check for CONNECT

Instead of looking for "200" and "established" (and failing all other
2xx responses or "Established"), let's look for a line that's not a
header (i.e. doesn't contain a ':') and where the first space is
followed by a '2'.

Fixes #1663

This looks good, except of the check for ':' which is not necessary.

You cannot guarantee that the first space in a header line will not be followed by a '2'...

I'm still concerned about retrieving only parts (e.g. the first 8 bytes) of the reply and not one full line as I have no idea about the BIO_gets() work. So tmp_search[1] could be the end of the string (\0) and the check may fail.

fbio is a buffered BIO, so BIO_gets() is guaranteed to get a full line, i.e. everything until a \n.

Having one line the check should be more easy to implement. In any case as soon as a SP is found and the upcoming character is not a '2' one can also exit.

No.  You need to read past all the headers.

PS: For my tests I also improved the error reporting, it may be nice to add it:

Good point, but a little more complex than what you did.  I'll figure something out.

@ You cannot guarantee that the first space in a header line will not be followed by a '2'...
https://tools.ietf.org/html/rfc7230#section-3.1.2 defines:
start-line     = request-line / status-line
status-line = HTTP-version SP status-code SP reason-phrase CRLF
HTTP-name = %x48.54.54.50 ; HTTP
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
status-code    = 3DIGIT

The RFC compliant server will always return "HTTP/d.d ddd Random Reason\r\n" as the first line.
The status code appears always after the first space and, and after reading the definitions, the 1st space is always at position 8. So no need to check it.
if ( (strlen(mbuf) > 10) && (mbuf[9]=='2')) {
        foundit++;
}

should be a safe check. Maybe >9 would be sufficient, I'm not sure about the C length checks.
PS: I just realized that my 1st for loop does hang forever as the 2nd call to BIO_gets() hangs if the initial call returned -1. But it's not needed anyway.

so @levitte what do you want to do with this?

I reimplemented it.  It should now satisfy a few things:

that the response status is the first line received (if not, something is seriously wrong)
that the response headers should be read past at all times if this is determined to be a HTTP response.

A local enum makes sense

Better?  (there are other instances of foundit that I will not fix in this PR)

Merged.
master: ec2a0e60652c0e61e90dde367756c5d92cd882d3
1.1.0: 07cd2f84d1480ca714bc14233b3c023ba9874e9d
No merge into 1.0.2, since that one doesn't support PROTO_CONNECT

Merged.
master: ec2a0e60652c0e61e90dde367756c5d92cd882d3
1.1.0: 07cd2f84d1480ca714bc14233b3c023ba9874e9d
No merge into 1.0.2, since that one doesn't support PROTO_CONNECT

authors: godly levitte richsalz


text:
Fix PKCS#7 inner contents verification

The general syntax for content according to RFC 2315 associates a content type with content.
ContentInfo ::= SEQUENCE {
     contentType ContentType,
     content
       [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

   ContentType ::= OBJECT IDENTIFIER

The data content type is just an octet string.
Data ::= OCTET STRING

Microsoft SignTool or osslsigncode  tool can digitally sign files.
Here is an example of parsing PKCS#7 signature.
p7->d.sign->contents starts at an offset 43 and has the V_ASN1_SEQUENCE type.
$ openssl asn1parse -i -inform pem -in sig.pem
    0:d=0  hl=4 l=1571 cons: SEQUENCE
    4:d=1  hl=2 l=   9 prim:  OBJECT            :pkcs7-signedData
   15:d=1  hl=4 l=1556 cons:  cont [ 0 ]
   19:d=2  hl=4 l=1552 cons:   SEQUENCE
   23:d=3  hl=2 l=   1 prim:    INTEGER           :01
   26:d=3  hl=2 l=  15 cons:    SET
   28:d=4  hl=2 l=  13 cons:     SEQUENCE
   30:d=5  hl=2 l=   9 prim:      OBJECT            :sha256
   41:d=5  hl=2 l=   0 prim:      NULL
   43:d=3  hl=2 l=  92 cons:    SEQUENCE
   45:d=4  hl=2 l=  10 prim:     OBJECT            :1.3.6.1.4.1.311.2.1.4
   57:d=4  hl=2 l=  78 cons:     cont [ 0 ]
   59:d=5  hl=2 l=  76 cons:      SEQUENCE
   61:d=6  hl=2 l=  23 cons:       SEQUENCE
   63:d=7  hl=2 l=  10 prim:        OBJECT            :1.3.6.1.4.1.311.2.1.15
   75:d=7  hl=2 l=   9 cons:        SEQUENCE
   77:d=8  hl=2 l=   1 prim:         BIT STRING
   80:d=8  hl=2 l=   4 cons:         cont [ 0 ]
   82:d=9  hl=2 l=   2 cons:          cont [ 2 ]
   84:d=10 hl=2 l=   0 prim:           cont [ 0 ]
   86:d=6  hl=2 l=  49 cons:       SEQUENCE
   88:d=7  hl=2 l=  13 cons:        SEQUENCE
   90:d=8  hl=2 l=   9 prim:         OBJECT            :sha256
  101:d=8  hl=2 l=   0 prim:         NULL
  103:d=7  hl=2 l=  32 prim:        OCTET STRING      [HEX DUMP]:2D2C7B382C8163A419B9FF214A7B651C33F9EA43335907F11377290C5158A7A4
  137:d=3  hl=4 l= 913 cons:    cont [ 0 ]
  141:d=4  hl=4 l= 909 cons:     SEQUENCE
  145:d=5  hl=4 l= 629 cons:      SEQUENCE
  149:d=6  hl=2 l=   3 cons:       cont [ 0 ]
  151:d=7  hl=2 l=   1 prim:        INTEGER           :02
  154:d=6  hl=2 l=  20 prim:       INTEGER           :1A2F945F4D1E9B68F8BFC6C9D6C707B03E35FDC7
  (...)

In the PKCS7_verify() function, the BIO *indata parameter refers to the signed data if the content is detached from p7. Otherwise, indata should be NULL, and then the signed data must be in p7. The content is written to the BIO out unless it is NULL.
Currently, the only supported types for p7->d.sign->contents are NID_pkcs7_data or V_ASN1_OCTET_STRING, due to restrictions in the PKCS7_get_octet_string() function.
My PR addresses this by adding support for p7->d.sign->contents with the V_ASN1_SEQUENCE type.

[x] tests are added or updated

CLA: regular

CI is relevant

This PR should be triaged as a bug, not a feature, I think.
According to the PKCS7_verify() manual:
indata refers to the signed data if the content is detached from p7. Otherwise indata should be NULL, and then the signed data must be in p7.

Without this PR, the inner content must be passed as detached content with the indata parameter.
This is a workaround to put the inner content into 'indata' parameter:
    BIO *bio = NULL;
    if (p7->d.sign->contents->d.other->type == V_ASN1_SEQUENCE) {
        /* only verify the contents of the sequence */
        unsigned char *data = p7->d.sign->contents->d.other->value.sequence->data;
        int len = p7->d.sign->contents->d.other->value.sequence->length;
        int hdrlen = ASN1_object_size(0, len, V_ASN1_SEQUENCE) - len;
        bio = BIO_new_mem_buf(data + hdrlen, length - hdrlen);
    }
    if (!PKCS7_verify(p7, NULL, store, bio, NULL, 0)) {
        /* Verification failure */
        (...)
    }

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

Please let me know if you need any help from me.

The CI failures must be fixed.

Do I correctly understand that this PR is ready for merging?

No, this still needs a second review.

Could the tests use stored file instead of hard-coded buffers?

Could the tests use stored file instead of hard-coded buffers?

I guess it could, but refactoring of an existing test for unrelated functionality is beyond the scope of this PR, and using different methods of retrieving the date in a single test source file would be a bad coding style.

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

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

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

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

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

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

ping @openssl/committers for the second review

Thanks for the review! I've applied the suggested changes, and the code works as expected. Let me know if anything else is needed.

@olszomal Could you please add a CHANGES.md entry?

@vdukhovni could you please re-approve

By the way, do you know whether Emilia's comment is still pertinent: https://github.com/openssl/openssl/blob/f1607c8a2c04bcb95ddb2e6fc4e0aaec9729929b/crypto/pkcs7/pk7_doit.c#L863-L870

By the way, do you know whether Emilia's comment is still pertinent:
https://github.com/openssl/openssl/blob/f1607c8a2c04bcb95ddb2e6fc4e0aaec9729929b/crypto/pkcs7/pk7_doit.c#L863-L870

No, Emilia's comment is no longer pertinent. I have verified that the path where os != NULL is now executed in cases involving PKCS#7 inner contents.

By the way, do you know whether Emilia's comment is still pertinent:
https://github.com/openssl/openssl/blob/f1607c8a2c04bcb95ddb2e6fc4e0aaec9729929b/crypto/pkcs7/pk7_doit.c#L863-L870

No, Emilia's comment is no longer pertinent. I have verified that the path where os != NULL is now executed in cases involving PKCS#7 inner contents.

I think Emilia was trying to say that the test os == NULL would never fire, were it not for some bug, so the question is not whether os != NULL, but whether it can be NULL here in some plausible error situation...

No, Emilia's comment is no longer pertinent. I have verified that the path where os != NULL is now executed in cases involving PKCS#7 inner contents.

I think Emilia was trying to say that the test os == NULL would never fire, were it not for some bug, so the question is not whether os != NULL, but whether it can be NULL here in some plausible error situation...

So, in my opinion, this issue seems to be outside the scope of this PR

No, Emilia's comment is no longer pertinent. I have verified that the path where os != NULL is now executed in cases involving PKCS#7 inner contents.

I think Emilia was trying to say that the test os == NULL would never fire, were it not for some bug, so the question is not whether os != NULL, but whether it can be NULL here in some plausible error situation...

So, in my opinion, this issue seems to be outside the scope of this PR

Yes, quite likely!  I was just wondering whether in working on the PR you have new insight on this otherwise terse comment, and perhaps happened to make it obsolete.  I am guessing not then...

@olszomal I've dismissed the outdated reviews requesting changes, so this should be ready to merge shortly. I would however be happy see you comment on the ASN1_STRING issue around the NDEF flag.

This pull request is ready to merge

Pushed to master. Thank you for your contribution.

authors: beldmit mattcaswell mtrojnar olszomal openssl-machine t8m vdukhovni


text:
Fix no-rmd160 classic Windows build

no-ripemd was unified a while ago but the change was not done in mk1mf.pl. This commit changes the no-ripemd string to no-rmd160 which fixes the no-rmd160 classic build.

+1

+1, can you merge @levitte ?

Sure

Done.  71627423e57882a038e65993c948b2ec78c837a1

authors: levitte matbech richsalz


text:
Extend generate_make_tasks documentation

Since this module generate tasks, it's good to get the actual parameters
we may pass down. This is especially important since the install_yamls
wrapper should be widely used in the framework.
Depends-On: https://github.com/openstack-k8s-operators/ci-framework/pull/223
As a pull request owner and reviewers, I checked that:

[ ] Appropriate testing is done and actually running
[X] Appropriate documentation exists and/or is up-to-date:

[ ] README in the role
[X] Content of the docs/source is reflecting the changes

/approve


text:
More zuul jobs, and generate JUnitXML reports for KUTTL

Add KUTTL and tempest zuul jobs (meant to replace the prow ones in the long term)
KUTTL: generate JUnitXML reports

switch the type to XML (the accepted value is 'xml' lowercase, not uppercase);
tune the name a bit to highlight it is a report;
add the new reportGranularity parameter which is supported by kuttl 0.20.0 and will restore the pre-1.17 JUnitXML format (granularity by test case, instead of by step).

recheck


text:
Empty commit to make place for the v0.4.0 tag

To be able to distinguish between pseudoversions from main and from 18.0.0-proposed we need to start tagging main with v0.4.0 while keeping 18.0.0-proposed using the v0.3.x tags. Naturally we would only need to start tagging after the first commit arrives to main. But to avoid forgetting the tagging at that point we add an empty commit and tag it instead.

/lgtm


text:
Inherit top-level nodeSelector in horizon template

Depends-On: https://github.com/openstack-k8s-operators/horizon-operator/pull/388
Jira: OSPRH-10734

Included in https://github.com/openstack-k8s-operators/openstack-operator/pull/1188


text:
Imagery used is only updated the first time the user attempts to save

Because of how this code is structured below, the imagery_used changeset tag is getting set only the first time a user attempts to save.
This means if a user cancels the save and does some more editing, whatever other imagery sources they use won't be included in the tag.
https://github.com/openstreetmap/iD/blob/fd4ca2368d0b28bd9968ccec5adaaedd5c79004d/modules/ui/commit.js#L63-L85
The fix is really easy - just remove
imagery_used: context.history().imageryUsed().join(';').substr(0, 255)
...from where the tags get set up inside the if block.
Instead move it just after the if block so the value gets updated every time this code is entered.
After the tags are cloned, edit the imagery_used property, and update the changeset like below.
tags = _clone(changeset.tags);
tags.imagery_used = context.history().imageryUsed().join(';').substr(0, 255);
changeset = changeset.update({ tags: tags });

NB: In case anyone is wondering, why bother with the clone/update stuff instead of just modifying changeset.tags directly - it's because we try to keep these osm objects immutable.

@ferdibiflator  this is the issue I mentioned in https://github.com/openstreetmap/iD/pull/4440#issuecomment-336715671
Let me know if you have time to make a PR for this too, thanks! 😄

repo: openstreetmap/iD

license: ISC


text:
Incorrect displaying of map after changing

I've changed my community in iD. So, it was changes since 15.02.2018 16:00
So, when I open OSM (not editor) first time (today) I didn't see any changes, but I saw, in different scales you can see changes, but incorrectly.
1st screenshot - Map in editor

2nd screenshot - Map after changes

3d screenshot - Map after changes in another scale

Hi @lujo777 - first, thank you for your edits!
What you're seeing is expected.  The rendered map on openstreetmap.org might not display the latest edits right away.  It takes some time (usually a few minutes) to update, and this will happen differently at different zoom levels.
The data that you see in the iD editor is the raw OSM data that is current as you navigate around the map.
https://wiki.openstreetmap.org/wiki/FAQ#I_have_just_made_some_changes_to_the_map._How_do_I_get_to_see_my_changes.3F

So, when we can see full changes?

So, when we can see full changes?

I don't know - it's not related to this project.
The FAQ I linked to has some info, and that contains links to some longer explanations:
https://wiki.openstreetmap.org/wiki/FAQ#I_have_just_made_some_changes_to_the_map._How_do_I_get_to_see_my_changes.3F


text:
Add Playground Map preset

playground=map should have a preset named Playground Map. As of writing, playground=map is one of the most widely used documented playground=* tags that doesn’t have an iD preset yet, with several less common tags already being supported. The Subject and Surface fields would both be relevant.

it's probably tricky to find a good name for this preset. Initially, I thought a "playground map" would be a (sign containing) a map of a playground. :speak_no_evil: Do you have an idea how we could name this accurately?

PS: This could also be a candidate for a subject:wikidata field (see #533)

repo: openstreetmap/id-tagging-schema


text:
feat: add inline chat reporter

Types

[x] 🎉 New Features

Background or solution
Changelog

/next

repo: opensumi/core

license: MIT


text:
feat(sdk): insecure plaintext and skip verify conn

resolves https://github.com/opentdf/platform/issues/631
breaking change in the SDK
// WithInsecurePlaintextConn returns an Option that sets up HTTP connection sent in the clear.
func WithInsecurePlaintextConn() Option {

// WithInsecureSkipVerifyConn returns an Option that sets up HTTPS connection without verification.
func WithInsecureSkipVerifyConn() Option {

Some log statement changes

In the future, use the breaking change convention
Subject feat(sdk)!: insecure plaintext and skip verify conn
Body/description:
BREAKING CHANGE:
.```
// WithInsecurePlaintextConn returns an Option that sets up HTTP connection sent in the clear.
func WithInsecurePlaintextConn() Option {

// WithInsecureSkipVerifyConn returns an Option that sets up HTTPS connection without verification.
func WithInsecureSkipVerifyConn() Option {
.```

- Some log statement changes"

authors: jrschumacher pflynn-virtru

repo: opentdf/platform


text:
Incorrect IPv6 and UDP header length fields in decompressed packets

When lowpan frames are decompressed, the constructed IPv6 and UDP header length fields include the appended CCM tag (length fields are larger by sizeof(tag)). In practice this is not a problem, because these raw values are not used, instead message.GetLength() is called to determine the payload size and it is updated correctly in Mle::HandleUdpReceive after the CCM decryption SuccessOrExit(aMessage.SetLength(aMessage.GetLength() - sizeof(messageTag)));. However this was quite confusing when I first dumped inbound packets on the host side and the buffer length did not match the header length field:
wpantund[24123]: [NCP->] CMD_PROP_VALUE_IS(PROP_STREAM_NET_INSECURE)
wpantund[24123]: [NCP->] IPv6 len:87 type:17(cksum 0xd74d) [INSECURE] [DROPPED]
60 00 00 00 00 33 11 ff    fe 80 00 00 00 00 00 00
7e f4 85 67 ae f4 56 55    ff 02 00 00 00 00 00 00
00 00 00 00 00 00 00 01    4d 4c 4d 4c 00 33 d7 4d
00 15 a0 01 00 00 00 00    00 00 01 04 00 02 90 00
0b 08 38 3e d6 fd 00 02    7e 24 09 0b cd 00 00 00
40 08 00 00 00 f1 01

This is probably not so important, as long as these frames are processed internally only.

@GiedriusM, MLE packets do not have MAC enabled, but instead have security enabled at the MLE layer.  Since MLE is part of the UDP payload, the tag should be included in the IPv6 and UDP length values.  What's happening here is that the MLE implementation is stripping off the tag after security processing and then the modified packet is being delivered to the host after MLE processing is done.
In general, processed MLE packets should probably not be exported to the host.  wpantund is just dropping them anyway, as you noted above.

Thanks! I had a similar feeling, however without having Thread specifications it's hard to determine whether something is a real bug or an attribute.

See #243.

Fixed in #243.

authors: GiedriusM jwhui

repo: openthread/openthread


text:
add feature measuring how long a track is actively sending or receiving data

defined by an increase in bytesReceived/bytes.
This doesn't work with unified plan because of
https://bugs.chromium.org/p/chromium/issues/detail?id=943493
which breaks our correlation between stats and ontrack

LGTM

authors: fippo ggarber

repo: opentok/rtcstats-server


text:
add message compression

from #18: lets also compress this, either using lzstring or a using a custom name mapping. Most likely lzstring which adds ~4kb download is the best solution.

1.6Kb gzipped   https://cdnjs.cloudflare.com/ajax/libs/lz-string/1.4.4/lz-string.min.js
There is a websocket deflate extension.  If we figure out how to enable it maybe we can get that with 0 effort and 0 extra KB and dependencies.

Sec-WebSocket-Extensions:permessage-deflate

-- already on? I had wondered because the actual traffic measured in wireshark was way lower than I expected when I looked. How did you actually measure, looking at the frames or with wireshark?

i think we resolved this, did we?

I thin we still didn't add lzstring, right?   But feel free to close it and I will create another if needed later.

https://github.com/nodeca/pako -- we could use this

repo: opentok/rtcstats


text:
log4j2 support

Hello,
Is there any plan to support lo4j2? It seems trace with logs not working when I check from UI.
I tried with logback, then I was able to see logs along with my application logs.
Thanks

This project purely instruments jax-rs. The integration with the logging framework is out of the scope of this project.
Putting trace context into logs has to be done at tracer initialization time as it requires changing the scope manager implementation https://github.com/quarkusio/quarkus/blob/master/extensions/jaeger/runtime/src/main/java/io/quarkus/jaeger/runtime/MDCScopeManager.java#L11

authors: pavolloffay seho-kim-do-something

repo: opentracing-contrib/java-jaxrs

license_source: bigquery


text:
Scope Manager: Should it return Noop-types for Scope.active / Tracer.activeSpan?

Java has recently merged https://github.com/opentracing/opentracing-java/pull/263 (and the same change is pending in C# (https://github.com/opentracing/opentracing-csharp/pull/84)) which changes the behavior of the NoopTracer: It will now always return NoopScope.INSTANCE and NoopSpanImpl.INSTANCE instead of null values.
However, if people rely on these methods to never return null then this will violate the current "Scope Manager" RFC (see quote below) and it will ultimately lead to null pointer exceptions when people switch from a NoopTracer to a real tracer.

active, the Scope containing the current active Span if any, or else null/nothing.

Did I misinterpret this risk? If not, should we revert this change in Java or should we change the RFC to state that ALL scope managers should return Noop-types for Scope.active and Tracer.activeSpan?
/cc @carlosalberto (author of the RFC)
/cc @natehart @yurishkuro (people who contributed to the Java PR)
/cc @MikeGoldsmith (people wo contributed to the C# PR)
PS: @carlosalberto the RFC currently doesn't mention the convenience accessor Tracer.activeSpan - should it be added to the RFC?

I think it was a bug in Java NoopTracer, which has been fixed. The Scope Manager concept is somewhat orthogonal to the Tracer (esp. https://github.com/opentracing/specification/issues/114), it should be possible to use a real thread-local based scope manager with a Noop tracer.

@yurishkuro I think it was a bug in Java NoopTracer, which has been fixed.

Yes and no. It probably was a bug that scopeManager.active() returned null after a call to scopeManager.activate(). But now active() also returns a scope even if activate() was never called. And this is a behavior that "real" scope managers do not share.

@cwe1ss I think there should be two ways of using NoopTracer, (a) with a normal ScopeManager (thread-local), and (b) with a lightweight NoopScopeManager. https://github.com/opentracing/opentracing-java/pull/263 implements the option (b), and only that option. I think is should also allow option (a). Specifically, this line
https://github.com/opentracing/opentracing-java/pull/263/files#diff-b9123283a173da56a32c0717b632bb76R35
is incorrect, it should delegate to scopeManager.active() instead of defaulting to noop span instance.

There was also this PR https://github.com/opentracing/opentracing-java/pull/167 related to this topic.
Switch from "real" tracer to noop shouldn't fail on NPE.

the RFC currently doesn't mention the convenience accessor Tracer.activeSpan - should it be added to the RFC?

I think this is more of sugar on top of the API, so I think this is not important to include in the specification itself.

IHMO, the issue/PR @pavolloffay would be a nice thing to have, and would also address the point @yurishkuro made.
Regarding the specification: I think we need to change/update it to reflect this (and add any clarification as needed). Good thing we are still in the draft stage of it ;)

// about opentracing-ruby
Returning NOOP_INSTANCE may get especially confusing with https://github.com/opentracing/specification/blob/master/rfc/trace_identifiers.md#specification-changes . E.g. a logging library may include something like
if tracer.active_span
  log_metadata[:trace_id] = tracer.active_span.context.trace_id
end

which doesn't really make sense if you have tracing disabled / working with noop instance. I'd rather not add a dummy trace_id to the logs if I'm dealing with a noop instance.

authors: carlosalberto cwe1ss indrekj pavolloffay yurishkuro

repo: opentracing/specification


text:
🛑 [CN] OpenUPM Website is down

In e498585, [CN] OpenUPM Website (https://openupm.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website is back up in 228cf0a after 9 minutes.

repo: openupm/upptime-openupmcn


text:
🛑 [CN] OpenUPM Website Docs is down

In 878cdaf, [CN] OpenUPM Website Docs (https://openupm.cn/docs/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Docs is back up in 56a974f after 8 minutes.


text:
🛑 [CN] OpenUPM Website Package Detail is down

In deec3ae, [CN] OpenUPM Website Package Detail (https://openupm.cn/packages/com.littlebigfun.addressable-importer/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Package Detail is back up in 5dcde91.


text:
🛑 [CN] OpenUPM API /packages/extra is down

In c102f85, [CN] OpenUPM API /packages/extra (https://api.openupm.cn/packages/extra) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM API /packages/extra is back up in fb8c2d2.

repo: openupm/upptime


text:
./gradlew assemble

./gradlew assemble
:buildJniLib
libtoolize: putting auxiliary files in .'. libtoolize: copying file ./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, m4'. libtoolize: copying file m4/libtool.m4'
libtoolize: copying file m4/ltoptions.m4' libtoolize: copying file m4/ltsugar.m4'
libtoolize: copying file m4/ltversion.m4' libtoolize: copying file m4/lt~obsolete.m4'
configure.ac:11: installing './compile'
configure.ac:11: installing './config.guess'
configure.ac:11: installing './config.sub'
configure.ac:9: installing './install-sh'
configure.ac:9: installing './missing'
src/main/c/Makefile.am: installing './depcomp'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format...                                                                                func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries...yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc option to accept ISO C99... -std=gnu99
checking for gcj... no
checking for guavac... no
checking for jikes... no
configure: error: no acceptable Java compiler found in $PATH
checking for javac... no
make: *** No rule to make target `install'.  Stop.
:buildJniLib FAILED
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':buildJniLib'.

Process 'command './build.sh'' finished with non-zero exit value 2

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED
Total time: 24.033 secs

There's no Java compiler on that machine. First install Java, then install the library.

There's no Java compiler on that machine. First install Java, then install the library.

But I do have Java compiler installed and I get the same error. Typing javac -version in CMD shows: javac 1.8.0_191

您好，邮件已收到，谢谢。Hello, mail has been received, thank you.

authors: BG864 thatdatabaseguy thx-fan

repo: openvenues/jpostal

license: mit


text:
[Bug]: Installation Error: Invalid requirement: 'torch>=2+cu121'

Describe the bug
I cloned the anomalib repo and switched to v1.1.0.
Following the Installation instructions on github:

pip install -e .
anomalib install --option core

The second command generated the error as below:

Also, I tried both on Windows and Ubuntu. It failed on both OS.
Dataset
N/A
Model
N/A
Steps to reproduce the behavior
AS shown in Description
OS information
N/A
Expected behavior
It should be installed successfully
Screenshots
No response
Pip/GitHub
GitHub
What version/branch did you use?
No response
Configuration YAML
NA

Logs
NA

Code of Conduct

[X] I agree to follow this project's Code of Conduct

By downgrading pip and setuptools, I got it to work.
Check this #2206
pip install --upgrade pip==24.0 setuptools==69.5.1  anomalib

Duplicate of #2156. We are aware of this, and will try to push a fix.

authors: hafid-Qa nickjyj samet-akcay

repo: openvinotoolkit/anomalib


text:
Cypress test. Settings. Show all interpolation tracks.

Motivation and context
Add Cypress test.
How has this been tested?

Checklist

[x] I submit my changes into the develop branch
[ ] I have added description of my changes into CHANGELOG file
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues (read github docs)
[ ] I have increased versions of npm packages if it is necessary (cvat-canvas,
cvat-core, cvat-data and cvat-ui)

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[x] I have updated the license header for each file (see an example below)

# Copyright (C) 2021 Intel Corporation
#
# SPDX-License-Identifier: MIT

Coverage decreased (-0.005%) to 70.293% when pulling dbd8ae3cca6085c588c990c41d9b098c526d4b9e on dvkruchinin:dkru/case-49-show-all-interpolation-tracks into 03804600419204fb2acf7a895c7ad439e646af32 on openvinotoolkit:develop.

Coverage decreased (-0.005%) to 70.293% when pulling dbd8ae3cca6085c588c990c41d9b098c526d4b9e on dvkruchinin:dkru/case-49-show-all-interpolation-tracks into 03804600419204fb2acf7a895c7ad439e646af32 on openvinotoolkit:develop.

authors: coveralls dvkruchinin

repo: openvinotoolkit/cvat


text:
Move install scripts and util.sh from openwhisk to openwhisk-catalog

Note: This issue is pre-req for other issues for "move" of catalog.
Please note that other issues (e.g., Issue 2, Issue 3) which are moving "utils" and "samples" package actions to new locations (and adjusting namespaces) will be updating these files. It may be a good idea to address (i.e., commit and merge) this issue before other issues titled "Move".
Please move the following files from the current repo. / directory "openwhisk-openwhisk/catalog" to this repo. under "openwhisk-catalog/packages":

installCatalog.sh

installGit.sh

installSlack.sh

installSystem.sh

installWatson.sh

installWeather.sh

util.sh

Refer to the issue in openwhisk-catalog: https://github.com/openwhisk/openwhisk-catalog/issues/4
Refer to the issue in IBM internal bluewhisk: https://github.ibm.com/BlueMix-Fabric/bluewhisk/issues/2032

Move implies the copy on this repo is deleted. But it's not. So are we keeping utils.sh?

authors: houshengbo rabbah

repo: openwhisk/openwhisk


text:
[feature] Integrate network topology with controller and monitoring modules

Still work in progress, but almost done, implements and closes #75.

Coverage decreased (-5.3%) to 93.702% when pulling ef134e1eb07811162fe453b92b78c0c2e3fcdb9d on 75-controller-integration into e7f99c0dcb7591e7278de19f66435e142af609c5 on dev.

authors: coveralls nemesisdesign

repo: openwisp/openwisp-network-topology


text:
[KeyField] Allow overrding default and validators #83

Closes #83

Coverage increased (+0.004%) to 98.976% when pulling 7a8bdfb171471f720eabacf1d10d8d7ac426b587 on key-field-override into 725f88bc5493f225c28b9cde39db52797995cfe7 on master.

repo: openwisp/openwisp-utils


text:
luci-theme-openwrt-2020: does not support table view

I fell maybe over the following css problem while testing the next stable branches. It looks like the table css definition is missing with this LuCI theme. I noticed thos first during my test for luci-app-dockerman with this theme. The luci-app-command also looks strange with this theme. Can anyone confirm this? @jow- do you have a fix for this?
luci-app-commands (dashboard):

luci-app-commands (config):
The button thing can be fixed by adding btn to the css class.

what is "this" in the "this theme"  ?

@hnyman no problem :-)
If I add the following to luci-theme-openwrt-2020 cascade.css:
diff --git a/themes/luci-theme-openwrt-2020/htdocs/luci-static/openwrt2020/cascade.css b/themes/luci-theme-openwrt-2020/htdocs/luci-static/openwrt2020/cascade.css
index aa811ef6d..b93fd2715 100644
--- a/themes/luci-theme-openwrt-2020/htdocs/luci-static/openwrt2020/cascade.css
+++ b/themes/luci-theme-openwrt-2020/htdocs/luci-static/openwrt2020/cascade.css
@@ -270,6 +270,28 @@ body.modal-overlay-active #modal_overlay {
  * table layout
  */

+.table {
+       display: flex;
+       flex-direction: column;
+       width: 100%;
+}
+
+.tr {
+       display: flex;
+       flex-direction: row;
+       flex-wrap: wrap;
+       align-items: flex-end;
+}
+
+.th, .td {
+       flex: 2 2 25%;
+       align-self: flex-start;
+       overflow: hidden;
+       text-overflow: ellipsis;
+       word-wrap: break-word;
+       display: inline-block;
+}
+
 table {
        width: 100%;
        margin: 0 0 1rem 0;

Then things look better. But I am not a CSS expert! Maybe there is someone who knows about it ;-)

Fixed with these commits:

f117b7f1e ("luci-app-commands: use  elements")
c5ff3244e ("luci-theme-openwrt-2020: honor CSS definitions passed by views")
215586817 ("luci-compat: update markup for CBI TableSections")

authors: feckert hnyman jow-

repo: openwrt/luci


text:
[ROCM] SDXL UNet attention dispatch after tiling+decomposition exceeds shared memory limit.

What happened?
dispatch benchmark IR for easy repro (compiled_unet_main_dispatch_91_rocm_hsaco_fb_benchmark.mlir):
module attributes {hal.device.targets = [#hal.device.target<"rocm", {executable_targets = [#hal.executable.target<"rocm", "rocm-hsaco-fb", {target_arch = "gfx1100", ukernels = "none"}>], legacy_sync}>]} {
  hal.executable private @main_dispatch_91 {
    hal.executable.variant public @rocm_hsaco_fb target(<"rocm", "rocm-hsaco-fb", {target_arch = "gfx1100", ukernels = "none"}>) {
      hal.executable.export public @main_dispatch_91_attention_20x4096x64xf16 ordinal(0) layout(#hal.pipeline.layout<push_constants = 4, sets = [<0, bindings = [<0, storage_buffer, ReadOnly>, <1, storage_buffer>]>]>) attributes {subgroup_size = 32 : index, translation_info = #iree_codegen.translation_info<LLVMGPUDistribute>, workgroup_size = [64 : index, 1 : index, 1 : index]} {
      ^bb0(%arg0: !hal.device):
        %x, %y, %z = flow.dispatch.workgroup_count_from_slice
        hal.return %x, %y, %z : index, index, index
      }
      builtin.module {
        func.func @main_dispatch_91_attention_20x4096x64xf16() {
          %0 = hal.interface.constant.load[0] : i32
          %1 = hal.interface.constant.load[1] : i32
          %2 = hal.interface.constant.load[2] : i32
          %3 = hal.interface.constant.load[3] : i32
          %4 = arith.index_castui %0 : i32 to index
          %5 = arith.index_castui %1 : i32 to index
          %6 = arith.index_castui %2 : i32 to index
          %7 = arith.index_castui %3 : i32 to index
          %8 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%4) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<20x4096x64xf16>>
          %9 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%5) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<20x4096x64xf16>>
          %10 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%6) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<20x4096x64xf16>>
          %11 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%7) : !flow.dispatch.tensor<writeonly:tensor<20x4096x64xf16>>
          %12 = flow.dispatch.tensor.load %8, offsets = [0, 0, 0], sizes = [20, 4096, 64], strides = [1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<20x4096x64xf16>> -> tensor<20x4096x64xf16>
          %13 = flow.dispatch.tensor.load %9, offsets = [0, 0, 0], sizes = [20, 4096, 64], strides = [1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<20x4096x64xf16>> -> tensor<20x4096x64xf16>
          %14 = flow.dispatch.tensor.load %10, offsets = [0, 0, 0], sizes = [20, 4096, 64], strides = [1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<20x4096x64xf16>> -> tensor<20x4096x64xf16>
          %15 = tensor.empty() : tensor<20x4096x64xf16>
          %16 = iree_linalg_ext.attention {lowering_config = #iree_codegen.lowering_config<tile_sizes = [[1, 64]]>} ins(%12, %13, %14 : tensor<20x4096x64xf16>, tensor<20x4096x64xf16>, tensor<20x4096x64xf16>) outs(%15 : tensor<20x4096x64xf16>) -> tensor<20x4096x64xf16>
          flow.dispatch.tensor.store %16, %11, offsets = [0, 0, 0], sizes = [20, 4096, 64], strides = [1, 1, 1] : tensor<20x4096x64xf16> -> !flow.dispatch.tensor<writeonly:tensor<20x4096x64xf16>>
          return
        }
      }
    }
  }
  util.global private mutable @main_dispatch_91_rocm_hsaco_fb_main_dispatch_91_attention_20x4096x64xf16_buffer : !hal.buffer
  util.initializer {
    %c839971840 = arith.constant 839971840 : index
    %c-1_i64 = arith.constant -1 : i64
    %c0 = arith.constant 0 : index
    %device_0 = hal.devices.get %c0 : !hal.device
    %allocator = hal.device.allocator<%device_0 : !hal.device> : !hal.allocator
    %buffer = hal.allocator.allocate<%allocator : !hal.allocator> affinity(%c-1_i64) type("DeviceVisible|DeviceLocal") usage("TransferSource|TransferTarget|Transfer|DispatchStorageRead|DispatchStorageWrite|DispatchStorage") : !hal.buffer{%c839971840}
    util.global.store %buffer, @main_dispatch_91_rocm_hsaco_fb_main_dispatch_91_attention_20x4096x64xf16_buffer : !hal.buffer
    util.return
  }
  util.func public @main_dispatch_91_rocm_hsaco_fb_main_dispatch_91_attention_20x4096x64xf16(%arg0: i32) attributes {iree.abi.stub, iree.reflection = {iree.benchmark = "dispatch"}} {
    %c-1_i32 = arith.constant -1 : i32
    %c-1_i64 = arith.constant -1 : i64
    %c419985920 = arith.constant 419985920 : index
    %c1 = arith.constant 1 : index
    %c419985728 = arith.constant 419985728 : index
    %c94927168_i32 = arith.constant 94927168 : i32
    %c136870208_i32 = arith.constant 136870208 : i32
    %c126384448_i32 = arith.constant 126384448 : i32
    %c84441408_i32 = arith.constant 84441408 : i32
    %c0 = arith.constant 0 : index
    %0 = arith.index_cast %arg0 : i32 to index
    %device_0 = hal.devices.get %c0 : !hal.device
    %cmd = hal.command_buffer.create device(%device_0 : !hal.device) mode("OneShot|AllowInlineExecution") categories(Dispatch) : !hal.command_buffer
    %pipeline_layout = hal.pipeline_layout.lookup device(%device_0 : !hal.device) layout(<push_constants = 4, sets = [<0, bindings = [<0, storage_buffer, ReadOnly>, <1, storage_buffer>]>]>) : !hal.pipeline_layout
    hal.command_buffer.push_constants<%cmd : !hal.command_buffer> layout(%pipeline_layout : !hal.pipeline_layout) offset(0) values([%c84441408_i32, %c126384448_i32, %c136870208_i32, %c94927168_i32]) : i32, i32, i32, i32
    %main_dispatch_91_rocm_hsaco_fb_main_dispatch_91_attention_20x4096x64xf16_buffer = util.global.load @main_dispatch_91_rocm_hsaco_fb_main_dispatch_91_attention_20x4096x64xf16_buffer : !hal.buffer
    hal.command_buffer.push_descriptor_set<%cmd : !hal.command_buffer> layout(%pipeline_layout : !hal.pipeline_layout)[%c0] bindings([
      %c0 = (%main_dispatch_91_rocm_hsaco_fb_main_dispatch_91_attention_20x4096x64xf16_buffer : !hal.buffer)[%c0, %c419985728],
      %c1 = (%main_dispatch_91_rocm_hsaco_fb_main_dispatch_91_attention_20x4096x64xf16_buffer : !hal.buffer)[%c419985920, %c419985728]
    ])
    %workgroup_x, %workgroup_y, %workgroup_z = hal.executable.calculate_workgroups device(%device_0 : !hal.device) target(@main_dispatch_91::@rocm_hsaco_fb::@main_dispatch_91_attention_20x4096x64xf16) : index, index, index
    %exe = hal.executable.lookup device(%device_0 : !hal.device) executable(@main_dispatch_91) : !hal.executable
    %ordinal = hal.executable.export.ordinal target(@main_dispatch_91::@rocm_hsaco_fb::@main_dispatch_91_attention_20x4096x64xf16) : index
    scf.for %arg1 = %c0 to %0 step %c1 {
      hal.command_buffer.dispatch<%cmd : !hal.command_buffer> target(%exe : !hal.executable)[%ordinal] workgroups([%workgroup_x, %workgroup_y, %workgroup_z])
      hal.command_buffer.execution_barrier<%cmd : !hal.command_buffer> source("Dispatch|CommandRetire") target("CommandIssue|Dispatch") flags("None")
    }
    hal.command_buffer.finalize<%cmd : !hal.command_buffer>
    %1 = util.null : !hal.fence
    %fence = hal.fence.create device(%device_0 : !hal.device) flags("None") : !hal.fence
    hal.device.queue.execute<%device_0 : !hal.device> affinity(%c-1_i64) wait(%1) signal(%fence) commands([%cmd])
    %status = hal.fence.await until([%fence]) timeout_millis(%c-1_i32) : i32
    util.status.check_ok %status, "failed to wait on timepoint"
    util.return
  }
}

Compiles successfully with this command:
iree-compile compiled_unet_main_dispatch_91_rocm_hsaco_fb_benchmark.mlir --iree-input-type=torch --iree-vm-bytecode-module-output-format=flatbuffer-binary --iree-hal-target-backends=rocm --iree-rocm-link-bc --iree-rocm-bc-dir=C:\AMD\ROCm\5.5\amdgcn\bitcode --mlir-print-debuginfo=false --mlir-print-op-on-diagnostic=false --iree-rocm-target-chip=gfx1100 --iree-opt-const-expr-hoisting=False --iree-codegen-linalg-max-constant-fold-elements=9223372036854775807 --iree-opt-strip-assertions=true --verify=false -o compiled_unet_main_dispatch_91_rocm_hsaco_fb_benchmark.vmfb

Runs into shared memory allocation over allowed limit at runtime:
iree-benchmark-module --device=rocm --module=compiled_unet_main_dispatch_91_rocm_hsaco_fb_benchmark.vmfb --parameters=model=./stable_diffusion_xl_base_1_0_unet.safetensors --function=main
C:\V\iree\experimental\rocm\native_executable.c:137: INVALID_ARGUMENT; function 'main_dispatch_91_attention_20x4096x64xf16' requested shared memory size of 66304 larger than allowed size of 65536; while invoking native function hal.executable.create; while calling import;
[ 1]   native hal.executable.create:0 -
[ 0] bytecode module.__init:298 C:\V\SHARK-Turbine\sdxl_attn\unet_rocm_dispatches\compiled_unet_main_dispatch_91_rocm_hsaco_fb_benchmark.mlir:40:18

The error is caught in the compiler if --iree-llvmgpu-shared-memory-limit=65536 is set in the compile CLI command.
I suppose we just need to change the tile size for the decomposed attention op, but I'm not sure of a good way to approach this. any help would be appreciated.
What component(s) does this issue relate to?
Compiler
Version information
Latest IREE (https://github.com/openxla/iree/commit/5d8907e82fc1eb741a4d4d27f5cae865323fd1d7)
(Notably enabled by https://github.com/openxla/iree/commit/946375cad71786462bcfd63dde6fe305d1e3b9ff)

Very similar issue on SDXL VAE:
python ..\models\turbine_models\custom_models\sdxl_inference\vae.py --compile_to=vmfb --external_weights=safetensors --device=rocm --variant="decode" --precision="fp16" --iree_target_triple=gfx1100 --external_weight_path=stable_diffusion_xl_base_1_0_vae.safetensors
C:\V\SHARK-Turbine\turb.env\Lib\site-packages\diffusers\utils\outputs.py:63: UserWarning: torch.utils._pytree._register_pytree_node is deprecated. Please use torch.utils._pytree.register_pytree_node instead.
  torch.utils._pytree._register_pytree_node(
C:\V\SHARK-Turbine\turb.env\Lib\site-packages\diffusers\utils\outputs.py:63: UserWarning: torch.utils._pytree._register_pytree_node is deprecated. Please use torch.utils._pytree.register_pytree_node instead.
  torch.utils._pytree._register_pytree_node(
Traceback (most recent call last):
  File "C:\V\SHARK-Turbine\models\turbine_models\custom_models\sdxl_inference\vae.py", line 156, in <module>
    mod_str = export_vae_model(
              ^^^^^^^^^^^^^^^^^
  File "C:\V\SHARK-Turbine\models\turbine_models\custom_models\sdxl_inference\vae.py", line 148, in export_vae_model
    utils.compile_to_vmfb(module_str, device, target_triple, max_alloc, safe_name)
  File "C:\V\SHARK-Turbine\models\turbine_models\custom_models\sd_inference\utils.py", line 99, in compile_to_vmfb
    flatbuffer_blob = ireec.compile_str(
                      ^^^^^^^^^^^^^^^^^^
  File "C:\V\iree-build\compiler\bindings\python\iree\compiler\tools\core.py", line 299, in compile_str
    result = invoke_immediate(cl, immediate_input=input_bytes)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\V\iree-build\compiler\bindings\python\iree\compiler\tools\binaries.py", line 198, in invoke_immediate
    raise CompilerToolError(process)
iree.compiler.tools.binaries.CompilerToolError: Error invoking IREE compiler tool iree-compile.exe
Error code: 1
Diagnostics:
<stdin>:638:14: error: 'func.func' op uses 221952 bytes of shared memory; exceeded the limit of 166912 bytes
    %172:2 = torch.operator "torch.aten._scaled_dot_product_flash_attention_for_cpu"(%165, %168, %171, %float0.000000e00, %false_169, %none_170, %none_171) : (!torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384,512],f16>, !torch.float, !torch.bool, !torch.none, !torch.none) -> (!torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384],f32>)
             ^
<stdin>:250:3: note: called from
  func.func @main(%arg0: tensor<1x4x128x128xf16>) -> tensor<1x3x1024x1024xf16> attributes {torch.args_schema = "[1, {\22type\22: \22builtins.tuple\22, \22context\22: \22null\22, \22children_spec\22: [{\22type\22: \22builtins.list\22, \22context\22: \22null\22, \22children_spec\22: [{\22type\22: null, \22context\22: null, \22children_spec\22: []}]}, {\22type\22: \22builtins.dict\22, \22context\22: \22[]\22, \22children_spec\22: []}]}]", torch.return_schema = "[1, {\22type\22: null, \22context\22: null, \22children_spec\22: []}]"} {
  ^
<stdin>:638:14: error: Failures have been detected while processing an MLIR pass pipeline
    %172:2 = torch.operator "torch.aten._scaled_dot_product_flash_attention_for_cpu"(%165, %168, %171, %float0.000000e00, %false_169, %none_170, %none_171) : (!torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384,512],f16>, !torch.float, !torch.bool, !torch.none, !torch.none) -> (!torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384],f32>)
             ^
<stdin>:250:3: note: called from
  func.func @main(%arg0: tensor<1x4x128x128xf16>) -> tensor<1x3x1024x1024xf16> attributes {torch.args_schema = "[1, {\22type\22: \22builtins.tuple\22, \22context\22: \22null\22, \22children_spec\22: [{\22type\22: \22builtins.list\22, \22context\22: \22null\22, \22children_spec\22: [{\22type\22: null, \22context\22: null, \22children_spec\22: []}]}, {\22type\22: \22builtins.dict\22, \22context\22: \22[]\22, \22children_spec\22: []}]}]", torch.return_schema = "[1, {\22type\22: null, \22context\22: null, \22children_spec\22: []}]"} {
  ^
<stdin>:638:14: note: Pipeline failed while executing [`TranslateExecutablesPass` on 'hal.executable' operation: @main_dispatch_10, `TranslateExecutablesPass` on 'hal.executable' operation: @main_dispatch_3, `TranslateTargetExecutableVariantsPass` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `TranslateTargetExecutableVariantsPass` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `TranslateExecutablesPass` on 'hal.executable' operation: @main_dispatch_17, `TranslateTargetExecutableVariantsPass` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `TranslateExecutablesPass` on 'hal.executable' operation: @main_dispatch_21, `TranslateTargetExecutableVariantsPass` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `TranslateExecutablesPass` on 'hal.executable' operation: @main_dispatch_22, `TranslateTargetExecutableVariantsPass` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `TranslateExecutablesPass` on 'hal.executable' operation: @main_dispatch_25, `TranslateTargetExecutableVariantsPass` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `TranslateExecutablesPass` on 'hal.executable' operation: @main_dispatch_26, `TranslateTargetExecutableVariantsPass` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `LLVMGPULowerExecutableTarget` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `TranslateExecutablesPass` on 'hal.executable' operation: @main_dispatch_27, `TranslateTargetExecutableVariantsPass` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `LLVMGPULowerExecutableTarget` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `TranslateExecutablesPass` on 'hal.executable' operation: @main_dispatch_40, `TranslateTargetExecutableVariantsPass` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `LLVMGPULowerExecutableTarget` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `LLVMGPULowerExecutableTarget` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `TranslateExecutablesPass` on 'hal.executable' operation: @main_dispatch_41, `TranslateTargetExecutableVariantsPass` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `TranslateExecutablesPass` on 'hal.executable' operation: @main_dispatch_83, `TranslateTargetExecutableVariantsPass` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `LLVMGPULowerExecutableTarget` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `TranslateExecutablesPass` on 'hal.executable' operation: @main_dispatch_84, `TranslateTargetExecutableVariantsPass` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `LLVMGPULowerExecutableTarget` on 'hal.executable.variant' operation: @rocm_hsaco_fb, `OptimizeTensorInsertExtractSlices` on 'func.func' operation: @main_dispatch_40_conv_2d_nchw_fchw_1x512x128x128x512x3x3_f16, `Canonicalizer` on 'builtin.module' operation, `GPUDistributeSharedMemoryCopy` on 'func.func' operation: @main_dispatch_27_generic_512x16384_f32xf16xf16xf16xf32, `Canonicalizer` on 'func.func' operation: @main_dispatch_17_conv_2d_nchw_fchw_1x512x128x128x512x3x3_f16, `IREEComprehensiveBufferize` on 'builtin.module' operation, `ConvertToROCDL` on 'builtin.module' operation, `FoldMemRefAliasOps` on 'func.func' operation: @main_dispatch_26_matmul_transpose_b_16384x512x512_f16xf16xf32, `ExtractAddressComputationGPU` on 'builtin.module' operation, `Canonicalizer` on 'func.func' operation: @main_dispatch_21_generic_32x16x16384_f16xf32xf32xf16xf16xf16, `GPUCheckResourceUsage` on 'builtin.module' operation, `LoopInvariantCodeMotion` on 'func.func' operation: @main_dispatch_22_matmul_transpose_b_16384x512x512_f16]: reproducer generated at `./shark_tmp/core-reproducer.mlir`
    %172:2 = torch.operator "torch.aten._scaled_dot_product_flash_attention_for_cpu"(%165, %168, %171, %float0.000000e00, %false_169, %none_170, %none_171) : (!torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384,512],f16>, !torch.float, !torch.bool, !torch.none, !torch.none) -> (!torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384],f32>)
             ^
<stdin>:638:14: error: failed to run translation of source executable to target executable for backend #hal.executable.target<"rocm", "rocm-hsaco-fb", {target_arch = "gfx1100", ukernels = "none"}>
    %172:2 = torch.operator "torch.aten._scaled_dot_product_flash_attention_for_cpu"(%165, %168, %171, %float0.000000e00, %false_169, %none_170, %none_171) : (!torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384,512],f16>, !torch.float, !torch.bool, !torch.none, !torch.none) -> (!torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384],f32>)
             ^
<stdin>:250:3: note: called from
  func.func @main(%arg0: tensor<1x4x128x128xf16>) -> tensor<1x3x1024x1024xf16> attributes {torch.args_schema = "[1, {\22type\22: \22builtins.tuple\22, \22context\22: \22null\22, \22children_spec\22: [{\22type\22: \22builtins.list\22, \22context\22: \22null\22, \22children_spec\22: [{\22type\22: null, \22context\22: null, \22children_spec\22: []}]}, {\22type\22: \22builtins.dict\22, \22context\22: \22[]\22, \22children_spec\22: []}]}]", torch.return_schema = "[1, {\22type\22: null, \22context\22: null, \22children_spec\22: []}]"} {
  ^
<stdin>:638:14: error: failed to translate executables
    %172:2 = torch.operator "torch.aten._scaled_dot_product_flash_attention_for_cpu"(%165, %168, %171, %float0.000000e00, %false_169, %none_170, %none_171) : (!torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384,512],f16>, !torch.float, !torch.bool, !torch.none, !torch.none) -> (!torch.vtensor<[1,1,16384,512],f16>, !torch.vtensor<[1,1,16384],f32>)
             ^
<stdin>:250:3: note: called from
  func.func @main(%arg0: tensor<1x4x128x128xf16>) -> tensor<1x3x1024x1024xf16> attributes {torch.args_schema = "[1, {\22type\22: \22builtins.tuple\22, \22context\22: \22null\22, \22children_spec\22: [{\22type\22: \22builtins.list\22, \22context\22: \22null\22, \22children_spec\22: [{\22type\22: null, \22context\22: null, \22children_spec\22: []}]}, {\22type\22: \22builtins.dict\22, \22context\22: \22[]\22, \22children_spec\22: []}]}]", torch.return_schema = "[1, {\22type\22: null, \22context\22: null, \22children_spec\22: []}]"} {
  ^

Invoked with:
 iree-compile.exe C:\V\iree-build\compiler\bindings\python\iree\compiler\tools\..\_mlir_libs\iree-compile.exe - --iree-input-type=auto --iree-vm-bytecode-module-output-format=flatbuffer-binary --iree-hal-target-backends=rocm --mlir-print-debuginfo --mlir-print-op-on-diagnostic=false --mlir-pass-pipeline-crash-reproducer=./shark_tmp/core-reproducer.mlir --iree-opt-strip-assertions=true --verify=false --iree-hal-target-backends=rocm --iree-rocm-target-chip=gfx1100 --iree-rocm-link-bc=true --iree-rocm-bc-dir=/opt/rocm/amdgcn/bitcode --iree-vm-bytecode-module-strip-source-map=true --iree-vm-target-truncate-unsupported-floats --iree-opt-const-expr-hoisting=False --iree-codegen-linalg-max-constant-fold-elements=9223372036854775807

Need more information? Set IREE_SAVE_TEMPS=/some/dir in your environment to save all artifacts and reproducers

IIUC we just need a good way to control/improve tiling for these tiled+decomposed attention op dispatches.

repo: openxla/iree


text:
Support default configs for BATCH_MATMUL_* in MaterializeEncoding pass

In #14705 we added BATCH_MATMUL_* encoding users and handled the materialization in IREE codegen path by providing a custom MaterializeEncodingFn. However MaterializeEncoding pass also can be called standalone, this change updates the default chooseEncodingInfo function to support new encoding users.
This is done by moving chooseEncodingInfoForMatmul under LinalgExt to reuse the logic of deciding materialization based on matmul encoding.
The problem was found when adding tests for MaterializeEncoding with BATCH_MATMUL_* encoding users, since MaterializeEncoding pass is called standalone by --iree-linalg-ext-materialize-encoding
#14431

@RoboTux FYI


text:
eval_module failed when compiling with gcc

What happened?
I found this bug when I try to use stablehlo's interpreter in torch-mlir. It could be reproduced at torch-mlir main branch:
from torch_mlir import ir
from torch_mlir._mlir_libs._stablehlo import eval_module
from torch_mlir._mlir_libs._stablehlo import register_dialect
import numpy as np

module_str = """
module attributes {torch.debug_module_name = "ArgmaxKeepdimModule"} {
  func.func @forward(%arg0: tensor<4x4xf32>, %arg1: tensor<4x4xf32>) -> tensor<4x4xf32> {
    %0 = stablehlo.add %arg0, %arg1 : tensor<4x4xf32>
    return %0 : tensor<4x4xf32>
  }
}
"""

with ir.Context() as context:
    register_dialect(context)
    module = ir.Module.parse(module_str)
    input = ir.DenseElementsAttr.get(np.random.random(size=(4, 4)).astype(np.float32))
    mlir_args = [input, input]
    rets = eval_module(module, mlir_args)
    print(rets)

It will produce error:
ValueError: input args must be DenseElementsAttr

BTW, it passed when compiling torch-mlir with clang.

_stablehlo.cpython-39-x86_64-linux-gnu.so have different *mlir* symbol between gcc and clang

I think it would also get the same failure when building stablehlo by gcc without torch-mlir.

I think previous issue(https://github.com/openxla/stablehlo/issues/2170) catch the same problem.

Thanks for raising this issue. Starting to understand the importance of not exposing mlir:: symbols in these APIs -- we plan to fix this up but timeline unknown, top of the refactoring priorities, but below feature development like DotAlgorithms.
We will not be adding any new APIs without proper CAPI shims, recently added register_all_passes with proper shim.

authors: GleasonK qingyunqu

repo: openxla/stablehlo


text:
Deploy less artifacts

Publishing to maven central takes a considerable amount of time, due to the large amount of artifacts we publish. The last sync was killed by circleci because it took over 10minutes to respond.
One way to reduce time is to publish less. For example, we can drop the long since deprecated brave-spancollector modules, and drop the test-only modules like brave-jersey2

Outdated issue, please close.

Closing. We can open separate issues or pull requests to stop publishing anything else that makes sense.

authors: adriancole jorgheymans shakuzen

repo: openzipkin/brave


text:
Fixes OSGi setup, missing for brave-instrumentation-http

cc @reta @cschneider noticed this testing CXF

Here's the manifest created:
$ cat META-INF/MANIFEST.MF
Manifest-Version: 1.0
Created-By: Apache Maven Bundle Plugin
Built-By: acole
Build-Jdk: 9.0.4
Automatic-Module-Name: brave.http
Bnd-LastModified: 1533039531838
Bundle-Description: Java implementation of Dapper (http://research.goo
 gle.com/pubs/pub36356.html) compatible with Zipkin (https://github.co
 m/twitter/zipkin/).
Bundle-DocURL: http://zipkin.io/
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion: 2
Bundle-Name: Brave Instrumentation: Http Adapters
Bundle-SymbolicName: io.zipkin.brave.instrumentation-http
Bundle-Vendor: OpenZipkin
Bundle-Version: 5.1.5.SNAPSHOT
Export-Package: brave.http;uses:="brave,brave.propagation,zipkin2";ver
 sion="5.1.5"
Import-Package: brave;version="[5.1,6)",brave.propagation;version="[5.
 1,6)",brave.sampler;version="[5.1,6)",zipkin2;version="[2.10,3)"
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.6))"
Tool: Bnd-3.5.0.201709291849

@@ -0,0 +1,5 @@
+Import-Package: \

!brave.internal*,\

Why is the exclusion of brave.internal necessary here? Does http access the
internal package?

well it uses brave.internal.Nullable which is runtime scope
annotation. That's it.. perhaps I'm being overly defensive?

That is totally fine. If the package is not exported by brave core you even
have to make sure it is not imported as else the bundle would not resolve
in OSGi.
Maybe you could add a comment to explain that only the annotation is used
and it is not necessary at runtime. I try to minimize such special settings
as they easily cause problems on refactorings or other changes. When I
still do them I try to explain so people know they can not simply be
removed.
Am Di., 31. Juli 2018 um 14:45 Uhr schrieb Adrian Cole <
notifications@github.com>:

@@ -0,0 +1,5 @@
+Import-Package: \

!brave.internal*,\

Why is the exclusion of brave.internal necessary here? Does http access
the
internal package?

well it uses brave.internal.Nullable which is runtime scope
annotation. That's it.. perhaps I'm being overly defensive?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openzipkin/brave/pull/743#issuecomment-409207820, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAdk6JD3cKJnHSVpTBM5uYLQ3Sn2WPavks5uMFFqgaJpZM4VoJj2
.

--
Christian Schneider
http://www.liquid-reality.de
Computer Scientist
http://www.adobe.com

@cschneider so I want to add this comment but I don't think the bnd file has comment syntax? If it does, can you tell me how?
Import-Package: \
  // We use brave.internal.Nullable, but nothing else internal.
  !brave.internal*,\
  *
Export-Package: \
  brave.http

authors: adriancole cschneider


text:
Fix for wrongly generated file name

chore(deps): update to Quarkus 2.7.0
fix: wrongly generated file name

Fixes #72

We should probably try to have some sort of integration test, actually, to check that the generated code actually creates a valid operator :)


text:
Method to trigger catalog container refresh

Feature Request
Is your feature request related to a problem? Please describe.
When we build an updated catalog image, we typically want to test against it immediately. Currently, that means manually bouncing the catalog pod.
Describe the solution you'd like
I'd like the build process to be able to trigger the catalog operator to check for a new image or perhaps just invalidate the current pod and force the creation of a new catalog pod.
I imagine that is an API endpoint I could hit or perhaps modifying the CatalogSource to set up a 'spec.refresh: true' item that it would remove as soon as it gets a new catalog built.

Rather sad to seeing this going stale.

I'm still interested in this.

Started discussion on Slack:
https://kubernetes.slack.com/archives/CAW0GV7A5/p1603113023166700

Evan Cordell pointed out on slack that simply changing the CatalogSource's image ref would serve the purpose using existing capability just fine.


text:
[WIP] clean-up: remove cluster provisioning from e2e

Description of the change:

Removes cluster provisioning from the e2e test suite and moves that responsibility to the Makefile
Adds bingo to the project to help manage the different tools needed for the project (e.g. kind, setup_envtest, helm, etc.)

Motivation for the change:
The project is currently a bit messy:

e2e suite doing things it shouldn't worry about
Makefile with stuff many don't understand/use
different build tags
scripts that could have been a couple of lines in the Makefile

So, trying to clean it up to make it easier to maintain
Architectural changes:
Testing remarks:
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Bug fixes are accompanied by regression test(s)
[ ] e2e tests and flake fixes are accompanied evidence of flake testing, e.g. executing the test 100(0) times
[ ] tech debt/todo is accompanied by issue link(s) in comments in the surrounding code
[ ] Tests are comprehensible, e.g. Ginkgo DSL is being used appropriately
[ ] Docs updated or added to /doc
[ ] Commit messages sensible and descriptive
[ ] Tests marked as [FLAKE] are truly flaky and have an issue
[ ] Code is properly formatted

closing in favor of #3222


text:
dse: Fix handling of nested aliases

@mloubout : hopefully this fixes the explosion in number of hoisted time invariants
can you check again with the use case you provided me with long time ago?

I want this PR to fix #970 too . Keeping it open for the time being, but it still needs some little work

Plans have changed. It will take a little more to fix #970 (I could fix it easily in fact, but I prefer a much more structured solution). So merging this for the time being,

repo: opesci/devito


text:
[Feature][Proxy] Squid on-disk cache should survive reboot

After reboot, the squid cache manager still shows roughly 80,000 objects as before the reboot but the objects are apparently gone. To reproduce: run the command squidclient -h theopnsensebox mgr:objects|grep GET before and after reboot.
The squid cache should survive the reboot.
I looked through /usr/local/etc/rc.d/squid but I could not find where this can be (un)configured. Squid's documentation says  that squid by default starts with a clean cache, not an empty cache. The cache dir itself survives the reboot as can be seen from the time stamps of the subdirectories and a core dump lying around.

you should check if your squid cache is stored on a ramdisk. You can set another directory in the squid configuration or uncheck the setting which makes it a ramdisk in the system settings (reboot required).

squid.conf: cache_dir ufs /var/squid/cache 262144 16 256
/var resides on SSD ("local cache" option is enabled):
# df
Filesystem      1K-blocks    Used     Avail Capacity  Mounted on
/dev/gpt/rootfs 479420532 6803100 434263792     2%    /
devfs                   1       1         0   100%    /dev
tmpfs            23492152     120  23492032     0%    /tmp
devfs                   1       1         0   100%    /var/dhcpd/dev

@borisneubert hey Boris, the cache dir chan be changed, but we also have squid_var_mfs="/var/squid/cache" support nowadays.
The problem: either we fix the squid cache dir again, or we have to let people use the directory override.
What do you think?

Uh, what is squid_var_mfs="/var/squid/cache" support? I know that the cache dir can be changed (UI: Web Proxy | Administration | General | Local Cache Settings (advanced) | Cache directory location).
Currently the cache resides on the same filesystem as the root filesystem. My preference had been to have a small root fs (e.g. 32 GB) and a large fs on another partition to host the cache. Whether this fs would have been mounted as /var/squid/cache or /something/else is not of importance for me.
BTW I did not check whether the observed issue still exists in OPNsense 17.7.10.

squid_var_mfs will make that directory persistent, we needed the same thing for ClamAV signature database persistency. But it does not make much sense if the cache dir can be set to somewhere else. The issue is the same on 17.7.11 / 18.1-BETA.

mfs= memory file system
MFS is OFF for my /var
Having /var (and /var/squid/cache) on MFS makes sense for small systems with SD card or USB sticks as storage medium to avoid early wear off.
I'd thus like to suggest the following:

/var/squid/cache can be moved anywhere (currently already possible)
full help for Web Proxy | Administration | General | Local Cache Settings (advanced) | Cache directory location should include a notice that the user should have a look at System | Settings | Miscellaneous | /var RAM disk ("if /var is on RAM disk, cache will emptied on reboot").
persistence of /var/squid/cache would then be explicitely given if the cache dir is /somewhere/else or if /var is not on RAM disk.
the option "Persist cache" would make sense if the cache is explicitely emptied if the option is unset and kept (no matter whether /var is on RAM disk or not) if the option is set.

Still not clear to me why my cache was emptied after reboot although /var is NOT on RAM disk.

Now I am confused. oO
I think points 1-3 are simply documentation issues. And is "Persist cache" an option you propose or am I just not able to find it in the code under that name?

Points 1-3 are simply documentation issues, right.
I thought that squid_var_mfs="/var/squid/cache" makes the the squid cache dir persist over reboots. My proposal was to

either do not have this at all (and stick to the points 1-3)
or to expose the option "Persist cache" in the UI, either keeping the cache content over reboots (if checked) or emptying the cache on reboot (if unchecked), no matter where the squid cache dir resides and if /var is on RAM disk or not.

Ok understood. Then we rather leave everything as is.
As to your missing cache, was this during first setup? Does it persist now? I'm asking because there was a bug report recently that could shed light on this: https://github.com/opnsense/core/issues/2008
Basically, if you select local cache, it says "service restart required" and hitting apply does not do that job... It's only picked up after reboot.

I observed the missing cache in July, most likely during initial tests, but the problem persisted over reboots.
I cannot reproduce the issue today. How did I proceed:

Downloaded a large file to desktop. CACHE_MISS
Downloaded the file again. CACHE_HIT
Rebooted OPNSense box and waited for Proxy Service to be up and running.
Downloaded the file again. CACHE_HIT

So I would say the issue can be closed.

Hi Boris,
ok thank you, can always reopen if new info is available
Cheers,
Franco

authors: borisneubert fabianfrz fichtner

repo: opnsense/core


text:
Support for WireGuard?

Hi,
I just read that WireGuard is about this be added to the Linux Kernel. Checking their website https://www.wireguard.com/ shows that it already supports quite a number of operating systems, FreeBSD as well.
Their setup guide on https://www.wireguard.com/quickstart/ looks quite daunting - how easy it is to
setup a tunnel :-)
Your OpenVPN implementation works for me, but my gut feeling tells me this is a good new product on the horizon worth supporting and implementing maybe - hopefully?
Regards
Thomas

Hi Thomas,
# pkg install wireguard

;)
A plugin is being discussed, but will not happen as long as wireguard considers itself "alpha software".
Cheers,
Franco

Yeah, updates in OPNsense for the package arrive in steadily via FreeBSD. I'll close this ticket. The time to discuss a plugin has not yet come. :)


text:
Make provision for fallover upon loss of gateway connection when using multiple WAN connections attached to different routers

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
[-] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
Yes
[-] I have searched the existing issues and I'm convinced that mine is new.
Yes
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I am trying to set up redundant routing using a local CARP interface.  I have two opnsense routers connected to two different ISPs.  I have configured one as the CARP master, which pushes relevant configuration to the backup.   When the master is down, this works as expected, and the backup takes over the CARP interface.   However, when the master loses its WAN connection, fallback does not occur because the master is still able to process packets
Describe the solution you'd like
A clear and concise description of what you want to happen.
(e.g. I would like an input field in the /ui/firewall/alias which would add .... to ....)
I would like OPNsense to be able to dynamically adjust the skew on the carp interface if the WAN link is down.  This can be accomplished using "sysctl net.inet.carp.demotion".  Ideally it should be able to increase its skew above the backup if there is no WAN traffic, and to drop it below the backup when WAN traffic is restored.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Alternatives are to configure a WAN group with routing from the master to the backup.  This is tricky to get working (I haven't managed it) and can result in packets taking a different route on send to return., which can lead to other problems.
Additional context
Add any other context or screenshots about the feature request here.

Practically I think this could be added by adding another option to firewall_virtual_ip_edit.php as follows:
Tickbox: Change skew if gateway down
Gateway: Dropdown of gateway or gateway group
Skew offset: positive or negative number
Then whatever code monitorrs the gateway status could apply/disapply the skew when the gateway status changes.

I'm not planning to work on this, but can give you some pointers on how this should work, since we added a similar mechanism for frr some time ago (https://github.com/opnsense/plugins/pull/1460).
https://docs.opnsense.org/development/backend/carp.html
The challenge here is to come to an easy to understand feature, since quite some people will expect different things here.

I'm not planning to work on this, but can give you some pointers on how this should work, since we added a similar mechanism for frr some time ago (opnsense/plugins#1460).
https://docs.opnsense.org/development/backend/carp.html
The challenge here is to come to an easy to understand feature, since quite some people will expect different things here.

.. or you change your network design so both units are master / slave or neither carp is used and you have dynamic routing internally

The issue is that there are NATed incoming services and both WAN links are dynamic IP which means I am reliant on dyndns, so I don't think I can make the routers interchangeable.   Even if I could, neither would gracefully fall back to the other on loss of gateway connectivity.
I think dynamic routing using OSPF may be an option, and I'll look into that some more I think.

It will fit really smart since also cheap 3rd party routers can run OSPF, or even some switches are capable :)

authors: AdSchellevis mimugmail sesquipedality