On Tue, Jun 25, 2024 at 9:18 AM Jan Beulich <jbeul...@suse.com> wrote: > > On 25.06.2024 14:39, Tamas K Lengyel wrote: > > On Tue, Jun 25, 2024 at 7:40 AM Jan Beulich <jbeul...@suse.com> wrote: > >> > >> On 25.06.2024 13:15, Tamas K Lengyel wrote: > >>> On Tue, Jun 25, 2024 at 5:17 AM Jan Beulich <jbeul...@suse.com> wrote: > >>>> > >>>> On 21.06.2024 21:14, Tamas K Lengyel wrote: > >>>>> --- /dev/null > >>>>> +++ b/scripts/oss-fuzz/build.sh > >>>>> @@ -0,0 +1,22 @@ > >>>>> +#!/bin/bash -eu > >>>>> +# Copyright 2024 Google LLC > >>>>> +# > >>>>> +# Licensed under the Apache License, Version 2.0 (the "License"); > >>>>> +# you may not use this file except in compliance with the License. > >>>>> +# You may obtain a copy of the License at > >>>>> +# > >>>>> +# http://www.apache.org/licenses/LICENSE-2.0 > >>>>> +# > >>>>> +# Unless required by applicable law or agreed to in writing, software > >>>>> +# distributed under the License is distributed on an "AS IS" BASIS, > >>>>> +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > >>>>> implied. > >>>>> +# See the License for the specific language governing permissions and > >>>>> +# limitations under the License. > >>>>> +# > >>>>> +################################################################################ > >>>> > >>>> I'm a little concerned here, but maybe I shouldn't be. According to what > >>>> I'm reading, the Apache 2.0 license is at least not entirely compatible > >>>> with GPLv2. While apparently the issue is solely with linking in Apache- > >>>> licensed code, I wonder whether us not having a respective file under > >>>> ./LICENSES/ (and no pre-cooked SPDX identifier to use) actually has a > >>>> reason possibly excluding the use of such code in the project. > >>>> > >>>>> +cd xen > >>>>> +./configure clang=y --disable-stubdom --disable-pvshim --disable-docs > >>>>> --disable-xen > >>>>> +make clang=y -C tools/include > >>>>> +make clang=y -C tools/fuzz/x86_instruction_emulator libfuzzer-harness > >>>>> +cp tools/fuzz/x86_instruction_emulator/libfuzzer-harness > >>>>> $OUT/x86_instruction_emulator > >>>> > >>>> In addition to what Julien said, I further think that filename / > >>>> directory > >>>> name are too generic for a file with this pretty specific contents. > >>> > >>> I don't really get your concern here? > >> > >> The thing that is built is specifically a x86 emulator piece of fuzzing > >> binary. Neither the directory name nor the file name contain either x86 > >> or (at least) emul. > > > > Because this build script is not necessarily restricted to build only > > this one harness in the future. Right now that's the only one that has > > a suitable libfuzzer harness, but the reason this build script is here > > is to be easily able to add additional fuzzing binaries without the > > need to open PRs on the oss-fuzz repo, which as I understand no one > > was willing to do in the xen community due to the CLA. Now that the > > integration is going to be in oss-fuzz, the only thing you have to do > > in the future is add more stuff to this script to get fuzzed. Anything > > that's compiled with libfuzzer and copied to $OUT will be picked up by > > oss-fuzz automatically. Makes sense? > > It does, yes. Yet nothing like that was said in the description. How > should anyone have known there are future possibilities with this script?
Apologies, to me "The build integration script for oss-fuzz targets." was sufficiently descriptive but it may require some familiarity with oss-fuzz to get. I can certainly add the above text to the commit message if that helps. Tamas
