search for: suppport

https://bugzilla.netfilter.org/show_bug.cgi?id=922 Summary: iprange: --ports is not suppported Product: nftables Version: unspecified Platform: x86_64 OS/Version: Debian GNU/Linux Status: NEW Severity: normal Priority: P5 Component: nft AssignedTo: pablo at netfilter.org ReportedBy: anarey at g...

> The MultiFS syntax is basically "(hdX,Y)/path/to/file", where X is disk > number and Y is partition number. > Thank you. As a reminder, please note: _ There was a syntax discussion about "multifs", so additional syntax forms should be allowed too (please read the whole email thread): http://www.syslinux.org/archives/2014-June/022173.html Examples: __ Space

On 07/23/2015 02:09 PM, Raphael S Carvalho via Syslinux wrote: >> > My sincere opinion is to apply this patchset as-is, and incrementally > improve multifs. Lack of alternatives (additional features) *should not* be > a reason to block this patchset. Again, I really think that this patchset > should be applied unless a technical reason, e.g. some deficiency > introduced by one

Ady, Peter, et al. On Fri, July 24, 2015 5:28 pm, Ady via Syslinux wrote: > >> On 07/23/2015 02:09 PM, Raphael S Carvalho via Syslinux wrote: >> >> >> > My sincere opinion is to apply this patchset as-is, and incrementally >> > improve multifs. Lack of alternatives (additional features) *should >> not* be >> > a reason to block this patchset.

... Syslinux MultiFS test: - QEMU/KVM SeaBIOS: PASSED - Bare-metal BIOS: FAILED [1] - OVMF: FAILED [2] - Bare-metal UEFI: not tested [1] stalled: Loading (hd3,2)/vmlinuz-4.3.2-200.fc22.x86_64... [2] "failed: No such file or directory" http://git.zytor.com/users/pcacjr/syslinux.git/tree/core/include/multifs.h?h=multifs-for-upstream#n27 * MULTIFS SYNTAX: * (hd[disk

On 09/02/15 10:59, Gene Cumm via Syslinux wrote: > On Fri, Jul 24, 2015 at 3:56 PM, H. Peter Anvin via Syslinux > <syslinux at zytor.com> wrote: >> On 07/23/2015 02:09 PM, Raphael S Carvalho via Syslinux wrote: >>>> >>> My sincere opinion is to apply this patchset as-is, and incrementally >>> improve multifs. Lack of alternatives (additional

Hi, facing [ no shared cipher ] error with EC private keys. This happens when the private key is generated with [ openssl ecparam -name brainpoolP512t1 -genkey ] with OpenSSL 1.1.0hh on the same machine Dovecot is running on. Tried some variations of [ ssl_cipher_list ] but to no avail - the [ no shared cipher ] error persists. Once the key is generated with [ openssl genpkey -algorithm RSA ]

Am 29.07.2018 um 21:06 schrieb ?????: > facing [ no shared cipher ] error with EC private keys. the client connecting to your instance has to support ecdsa Andreas

On 29.07.2018 23:39, ????? wrote: >>> facing [ no shared cipher ] error with EC private keys. >> the client connecting to your instance has to support ecdsa >> >> > It does - Thunderbird 60.0b10 (64-bit) > > [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ] > > It seems there is a difference between the private key (rsa vs. ecc -> > SSL_CTX?)

> On 29 July 2018 at 23:39 ????? <vtol at gmx.net> wrote: > > > > >> facing [ no shared cipher ] error with EC private keys. > > the client connecting to your instance has to support ecdsa > > > > > > It does - Thunderbird 60.0b10 (64-bit) > > [ security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384;true ] > > It seems there is a

>> >>> I did some local testing and it seems that you are using a curve >>> that is not acceptable for openssl as a server key. >>> I tested with openssl s_server -cert ec-cert.pem -key ec-key.pem >>> -port 5555 >>> using cert generated with brainpool. Everything works if I use >>> prime256v1 or secp521r1. This is a limitation in OpenSSL

> Perhaps for whose interested - IETF RFC 7027 specifies for TLS use: > > [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ] > > And thus t1 would not work anyway. However, having tested r1 the result > was just the same. > > A tcpdump during the openssl test [ s_server | s_client ] then revealed > (TLSv1.2 Record Layer: Handshake Protocol: Client Hello) : > >

> >>> Perhaps for whose interested - IETF RFC 7027 specifies for TLS use: >>> >>> [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ] >>> >>> And thus t1 would not work anyway. However, having tested r1 the result >>> was just the same. >>> >>> A tcpdump during the openssl test [ s_server | s_client ] then revealed

> Yeah, it needs to be recompiled to fix. > Sure, no worries.? Thanks for the quick turnaround on the patch. Downstream is notified and pending migration into their package. Meanwhile ssl_alt_key/certs does the trick. I am grateful that such option is even provisioned or else I would a be in rather bad spot with the CA. Other apps are rather ignorant on that matter.

On 31.07.2018 09:30, ????? wrote: >>>> Perhaps for whose interested - IETF RFC 7027 specifies for TLS use: >>>> >>>> [ brainpoolP256r1 | brainpoolP384r1 | brainpoolP512r1 ] >>>> >>>> And thus t1 would not work anyway. However, having tested r1 the result >>>> was just the same. >>>> >>>> A tcpdump

> On 30 July 2018 at 20:01 ????? <vtol at gmx.net> wrote: > > > > >>>> facing [ no shared cipher ] error with EC private keys. > >>> the client connecting to your instance has to support ecdsa > >>> > >>> > >> It does - Thunderbird 60.0b10 (64-bit) > >> > >> [

On 20.12.2015 09:55, poma wrote: > ... > > Syslinux MultiFS test: > > - QEMU/KVM SeaBIOS: PASSED > - Bare-metal BIOS: FAILED [1] > - OVMF: FAILED [2] > - Bare-metal UEFI: not tested > > > [1] stalled: > Loading (hd3,2)/vmlinuz-4.3.2-200.fc22.x86_64... > > > [2] "failed: No such file or directory" > >

On Fri, Jul 24, 2015 at 3:56 PM, H. Peter Anvin via Syslinux <syslinux at zytor.com> wrote: > On 07/23/2015 02:09 PM, Raphael S Carvalho via Syslinux wrote: >>> >> My sincere opinion is to apply this patchset as-is, and incrementally >> improve multifs. Lack of alternatives (additional features) *should not* be >> a reason to block this patchset. Again, I really

>>>> I did some local testing and it seems that you are using a curve >>>> that is not acceptable for openssl as a server key. >>>> I tested with openssl s_server -cert ec-cert.pem -key ec-key.pem >>>> -port 5555 >>>> using cert generated with brainpool. Everything works if I use >>>> prime256v1 or secp521r1. This is a

On Wed, Jul 22, 2015 at 11:15 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > > > The MultiFS syntax is basically "(hdX,Y)/path/to/file", where X is disk > > number and Y is partition number. > > > > Thank you. > > As a reminder, please note: > > _ There was a syntax discussion about "multifs", so additional syntax > forms