So, as some of you know the installer hits ftp.openbsd.org during the
install process to query a CGI to provide you with a list of nearby mirrors
and some other useful things.
I've recently made some changes to modernize and improve this after
the retirement of the GEO:IP
On Tue, Apr 28, 2020 at 11:16:43PM +0200, Patrick Wildt wrote:
> Hi,
>
> on my i.MX8MM EVK there's a ath10k-based WiFi chip which we
> unfortunately do not support (yet?). But the SD/MMC CIS parser
> complains:
>
> sdmmc0: CIS parse error at 4136, tuple code 0x14, length 0
> manufacturer
Hi,
on my i.MX8MM EVK there's a ath10k-based WiFi chip which we
unfortunately do not support (yet?). But the SD/MMC CIS parser
complains:
sdmmc0: CIS parse error at 4136, tuple code 0x14, length 0
manufacturer 0x0271, product 0x0701 at sdmmc0 function 1 not configured
It's not a transmission
...after some more research:
ec2n never actually made it into the IKEv2 RFC, it was present in drafts
up to 15, but removed in
https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-ipsec-ikev2-16.txt
the relevant entry from https://datatracker.ietf.org/doc/rfc4306/history/ is
:
If so, immediately. That means for about 2 weeks someone in snaps
can scream.
Tobias Heider wrote:
> On Tue, Apr 28, 2020 at 11:22:02AM +0100, Stuart Henderson wrote:
> > On 2020/04/28 01:09, Tobias Heider wrote:
> > > Hi,
> > >
> > > the EC2N family of curves have been marked as insecure for
April 28, 2020 11:02 AM, "Joerg Jung" mailto:m...@umaxx.net?to=%22Joerg%20Jung%22%20)> wrote:
On 28. Apr 2020, at 10:10, gil...@poolp.org (mailto:gil...@poolp.org) wrote:
April 28, 2020 8:55 AM, "Joerg Jung" mailto:m...@umaxx.net)>
wrote:
Also this change might break existing valid setups
On Tue, Apr 28, 2020 at 11:22:02AM +0100, Stuart Henderson wrote:
> On 2020/04/28 01:09, Tobias Heider wrote:
> > Hi,
> >
> > the EC2N family of curves have been marked as insecure for at least 10
> > years.
> > In fact, IANA has stopped listing them altogether [1].
> > Their former IDs are now
On Sun, 26 Apr 2020 18:30:25 +0200, Eric Faurot wrote:
> When a catch-all entry (@) is used in a virtual alias table, it
> eventually (and mistakenly) catches everything that expands to a
> username. For example, with:
>
> f...@example.com user
> @catchall
>
>
On 28/04/20(Tue) 11:56, Mark Kettenis wrote:
> > Date: Tue, 28 Apr 2020 11:40:17 +0200
> > From: Martin Pieuchot
> >
> > On 27/04/20(Mon) 19:34, Martin Pieuchot wrote:
> > > On 28/04/20(Tue) 01:54, Jonathan Gray wrote:
> > > > On Mon, Apr 27, 2020 at 04:52:33PM +0200, Martin Pieuchot wrote:
> >
On 2020/04/28 01:09, Tobias Heider wrote:
> Hi,
>
> the EC2N family of curves have been marked as insecure for at least 10 years.
> In fact, IANA has stopped listing them altogether [1].
> Their former IDs are now 'reserved'.
>
> I think it's time for us to drop them as well.
>
> ok?
I agree
> Date: Tue, 28 Apr 2020 11:40:17 +0200
> From: Martin Pieuchot
>
> On 27/04/20(Mon) 19:34, Martin Pieuchot wrote:
> > On 28/04/20(Tue) 01:54, Jonathan Gray wrote:
> > > On Mon, Apr 27, 2020 at 04:52:33PM +0200, Martin Pieuchot wrote:
> > > > Diff below extends the existing drmkqfilter() to
On 27/04/20(Mon) 19:34, Martin Pieuchot wrote:
> On 28/04/20(Tue) 01:54, Jonathan Gray wrote:
> > On Mon, Apr 27, 2020 at 04:52:33PM +0200, Martin Pieuchot wrote:
> > > Diff below extends the existing drmkqfilter() to support EVFILT_READ.
> > > This makes drm(4)'s kqueue support in pair with
> On 28. Apr 2020, at 10:10, gil...@poolp.org wrote:
> April 28, 2020 8:55 AM, "Joerg Jung" mailto:m...@umaxx.net>>
> wrote:
>
>> Also this change might break existing valid setups (e.g. with mailing list
>> servers), but people will likely know how to cope with it.
>
> Do you have an example
April 28, 2020 8:55 AM, "Joerg Jung" wrote:
>> On 26. Apr 2020, at 18:30, Eric Faurot wrote:
>>
>> When a catch-all entry (@) is used in a virtual alias table, it
>> eventually (and mistakenly) catches everything that expands to a
>> username. For example, with:
>>
>> f...@example.com user
>>
> On 26. Apr 2020, at 18:30, Eric Faurot wrote:
>
> When a catch-all entry (@) is used in a virtual alias table, it
> eventually (and mistakenly) catches everything that expands to a
> username. For example, with:
>
>f...@example.com user
>@catchall
>
>
Hello,
> That's a bug, updated diff below.
>
OK I see. the diff looks better then.
> If there's a consensus that this is a way to move forward, it would make
> sense to commit it after unlock.
>
I have not spot anything else. I think this change should go in.
OK sashan@
16 matches
Mail list logo
