> There is already HTTPS to protect the "authenticity" of the magnet
> link.
No. FreeBSD fails to publish signed fingerprints of their TLS pubkeys,
therefore users can't pin them down, therefore any MITM can bypass
CA game and MITM attack users at will, feed them bogus infohash,
isos, git repo
On Thu, 31 Dec 2020 11:39:08 -0800
John-Mark Gurney wrote:
> grarpamp wrote this message on Wed, Dec 30, 2020 at 00:55 -0500:
> > > signatures of the magnet links
> >
> > Signing torrent.asc, with stronger or even same hash as BT
> > protocol, still serve purpose of authenticate torrent file
On 12/31/20 5:47 PM, Daniel Eischen wrote:
On Thu, 31 Dec 2020, Daniel Eischen wrote:
I see this message in src/UPDATING:
20201216:
The services database has been updated to cover more of the basic
services expected in a modern system. The database is big enough
that it will cause issues
On 12/31/20 11:51 AM, Allan Jude wrote:
> We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
>
> I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal
> knowledge" that 'to
Just fyi, I have put a patch up on phabricator as D27875 that seems
to fix the problem for all NFS client mounts except NFSv4.0.
NFSv4.0 will require an additional fix so that the "seqid" is
properly maintained during redos of the Open caused by
the ERELOOKUP redo.
If anyone is running a recent
On 12/31/20 2:40 PM, Chuck Tuffli wrote:
> On Wed, Dec 30, 2020 at 4:38 PM Neel Chauhan wrote:
>>
>> Hi Chuck,
>>
>> On 2020-12-30 10:04, Chuck Tuffli wrote:
>>> What is the output from
>>> # pciconf -rb pci0:0:14:0 0x40:0x48
>>
>> The output is:
>>
>> 01 00 00 00 01 2e 68 02 00
>
> Perfect.
On 12/31/20 12:15 PM, Franco Fichtner wrote:
> https://cgit.freebsd.org/src/commit/sys/crypto/aesni?h=stable/12=95b37a4ed741fd116809d0f2cb295c4e9977f5b6
>
> may have subtly broken a number of IPsec installations by stalling active
> connections after certain amounts of traffic transferred. We're
On Thu, 31 Dec 2020, Daniel Eischen wrote:
I see this message in src/UPDATING:
20201216:
The services database has been updated to cover more of the basic
services expected in a modern system. The database is big enough
that it will cause issues in mergemaster in Releases previous to
12.2
On Thu, 2020-12-31 at 14:09 -0800, Rodney W. Grimes wrote:
> > We've had the AESNI module for quite a few years now, and it has
> > not
> > caused any problems.
> >
> > I am wondering if there are any objections to including it in
> > GENERIC,
> > so that users get the benefit without having to
On Wed, Dec 30, 2020 at 4:38 PM Neel Chauhan wrote:
>
> Hi Chuck,
>
> On 2020-12-30 10:04, Chuck Tuffli wrote:
> > What is the output from
> > # pciconf -rb pci0:0:14:0 0x40:0x48
>
> The output is:
>
> 01 00 00 00 01 2e 68 02 00
Perfect. The Linux driver says the 8086:9a0b device you have "...
On 12/30/20 9:45 PM, Neel Chauhan wrote:
> For reference, I am attaching the `pciconf -lv` and `acpidump -dt`
> dumps.
Hmm, the acpidump doesn't have the -d contents, only the -t, and
PCI bridges are generally enumerated in the the -d part. These
PCI bridges aren't enumerated in ACPI though, so
On Thu, Dec 31, 2020 at 3:20 PM Kristof Provost wrote:
> On 31 Dec 2020, at 23:09, Rodney W. Grimes wrote:
> > Its for ever dead code on a large number of machines that do not have
> > the hardware for it. I know that is a decreasing set, but imho it
> > would be better to somehow ONLY load the
On 31 Dec 2020, at 23:09, Rodney W. Grimes wrote:
Its for ever dead code on a large number of machines that do not have
the hardware for it. I know that is a decreasing set, but imho it
would be better to somehow ONLY load the module if you had CPU
support for it. The down side is that
> We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
>
> I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal
> knowledge" that 'to accelerate kernel crypto (GELI, ZFS,
On 2020-12-31 11:51, Allan Jude wrote:
We've had the AESNI module for quite a few years now, and it has not
caused any problems.
I am wondering if there are any objections to including it in GENERIC,
so that users get the benefit without having to have the "tribal
knowledge" that 'to accelerate
Yes! Took me until last month to notice that I needed to load aesni in
loader.conf instead of rc.conf because swap geli is configured before kld_list.
Years of optimization thrown away.
Regards,
Ronald.
Van: Allan Jude
Datum: 31 december 2020 20:51
Aan: FreeBSD Current
Onderwerp:
https://cgit.freebsd.org/src/commit/sys/crypto/aesni?h=stable/12=95b37a4ed741fd116809d0f2cb295c4e9977f5b6
may have subtly broken a number of IPsec installations by stalling active
connections after certain amounts of traffic transferred. We're still
trying to confirm, but it looks like this had
On Thu, Dec 31, 2020 at 02:51:06PM -0500, Allan Jude wrote:
> We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
>
> I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal
>
We've had the AESNI module for quite a few years now, and it has not
caused any problems.
I am wondering if there are any objections to including it in GENERIC,
so that users get the benefit without having to have the "tribal
knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
grarpamp wrote this message on Wed, Dec 30, 2020 at 00:55 -0500:
> > signatures of the magnet links
>
> Signing torrent.asc, with stronger or even same hash as BT
> protocol, still serve purpose of authenticate torrent file back
> to a signer to the degree therein, caveat their platform security,
I see this message in src/UPDATING:
20201216:
The services database has been updated to cover more of the basic
services expected in a modern system. The database is big enough
that it will cause issues in mergemaster in Releases previous to
12.2 and 11.3, or in very old current systems
On Thu, Dec 31, 2020 at 05:16:27AM +, Rick Macklem wrote:
> Rick Macklem wrote:
> >Kostik wrote:
> > >
> > >Idea of the change is to restart the syscall at top level. So for NFS
> > >server the right approach is to not send a response and also to not
> > >free the request mbuf chain, but to
In brief (for example):
grahamperrin@mowa219-gjp4-8570p:~ % ls -dhl /media/da1p1
drwxr-xr-x 3 root wheel 512B 30 Dec 13:29 /media/da1p1
grahamperrin@mowa219-gjp4-8570p:~ % touch /media/da1p1/touched
touch: /media/da1p1/touched: Permission denied
– is drwxr-xr-x as a default the norm?
In
23 matches
Mail list logo
