Daniel Kiper on Fri, 2025/02/28 13:57:
> On Thu, Feb 27, 2025 at 11:03:44AM +0100, Christian Hesse wrote:
> > Daniel Kiper via Grub-devel on Mon, 2025/02/24
> > 15:34:
> > > > [...]
> > > > The current situation is just insane.
> > >
> > > I can understand your frustration but I am afraid we
FreeBSD loader always passes "elf kernel". -CURRENT kernel accepts only
"elf kernel", older kernel accepts either.
Tested on FreeBSD and DragonFlyBSD
Reference:
https://cgit.freebsd.org/src/commit/?id=b72ae900d4348118829fe04abdc11b620930c30f
Signed-off-by: Vladimir Serbinenko
---
grub-core/lo
When using syntax hd0,gtp3,dfly1 then ptr points to trailing part ",dfly1"
so it's improper to consider it invalid partition
Signed-off-by: Vladimir Serbinenko
---
grub-core/kern/partition.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grub-core/kern/partition.c b/grub-cor
tss2_structs.h contains a duplicate typedef as follows:
typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF2_t;
This causes a build failure when compiling with clang 14
that can be seen as follows:
export CC=clang
export CXX=clang++
./configure
make
In file included from ./grub-core/commands/tpm2_key_prote
>> by a Windows application. Thanks for any information. Should the lockdown
>> for NTFS remain, is it here to stay indefinitely?
>
>We did a lot of work to improve the NTFS code but still we are not sure
>it is fully correct. If somebody will do full NTFS code analysis and
>properly fix all (poten
tss2_structs.h contains a duplicate typedef as follows:
typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF2_t;
This causes a build failure when compiling with clang.
Remove the duplicate typedef which allows successfully
building GRUB with clang.
Signed-off-by: Andrew Hamilton
---
grub-core/lib/tss2/ts
Hi,
Glenn Washburn wrote:
> Seems like running them the tests before
> committing large patch series, like this security update, might be a
> good idea.
I think that any change of the filesystem code should be tested as
much as possible.
But it is quite some hurdle that some of the tests need to
Why do you remove boundary check? Maybe it's better to add the second
boundary check from below
Le ven. 28 févr. 2025, 16:11, B Horn a écrit :
> On some NTFS volumes GRUB would enter an infinite loop when
> next_attribute() returned NULL, which can happen in normal cases when
> the end of the at
Hi,
Glenn Washburn wrote:
> Seems like running them the tests before
> committing large patch series, like this security update, might be a
> good idea.
I think that any change of the filesystem code should be tested as
much as possible.
But it is quite some hurdle that some of the tests need to