Security vulnerabilities affects core API authorization of gnu.org

[Salah Mosbah via Gcc]

Hi Janus,

How can I report some high impact security vulnerabilities that I have
found on gnu.org
web app?

Also, does gnu.org has a bug bounty program or reporting bugs reward policy?

The vulnerabilities that I have found affects the core API of gnu.org which
allows unauthorized users to get access to other user's data that they
don't have access to it.

Regards,
-Salah

https://hackerone.com/salaheldeen101
https://bugcrowd.com/Salah-Mosbah

Copyright assignment for Rust-GCC

[Nala Ginrut via Gcc]

Hi Folks!
This mail is about the development of Rust frontend of GCC.

To avoid misunderstanding, please let me introduce Rust-GCC briefly.
In 2013, Philip Herron had announced the project in GCC mailing-list:
https://gcc.gnu.org/legacy-ml/gcc/2013-12/msg00017.html
In 2019, @SimplyTheOther had contributed the almost complete parser and
AST.
And I helped to do some trival work to make it work with the latest GCC
at that time.
Of course there're more contributors that I can't mention one by one.
At that time, a small community of Rust-GCC had formed. We're interested
in continuing it till it can be merged into GCC.
https://github.com/Rust-GCC/gccrs
So this is the brief history.

Now we have a question, when should we assign copyright paper for GNU?
Last time I assigned the copyright paper, I noticed that the paper
mentioned the project name. But Rust-GCC hasn't been recogonized by GCC
community yet, so I'm not sure if it's the correct time to consider this
issue.

Comments are welcome.

Best regards.


--
GNU Powered it
GPL Protected it
GOD Blessed it
HFG - NalaGinrut
Fingerprint F53B 4C56 95B5 E4D5 6093 4324 8469 6772 846A 0058


signature.asc
Description: PGP signature

Re: What is the type of vector signed + vector unsigned?

[Richard Biener via Gcc]

On Tue, Dec 29, 2020 at 8:19 PM Alexander Monakov  wrote:
>
> On Tue, 29 Dec 2020, Richard Biener via Gcc wrote:
>
> > >I think clang follows gcc and uses the type of the first operand.
> >
> > The desired behavior is the one that OpenCL specifies. If it is 
> > implementation
> > defined we should document behavior. I agree symmetry is nice but eventually
> > the current C behavior is what OpenCL specifies.
>
> Where does OpenCL specify that? Checking the 1.2 OpenCL standard I see the
> opposite (the code would fail to compile):
>
> 6.2.1
> Implicit Conversions
>
> [...]
>
> Implicit conversions between built-in vector data types are disallowed.

But then in 6.4 it says operations operate component-wise not saying anything
about type requirements ... which suggests that

 int4 i;
 uint4 u;

 i = i + u;

is valid and is implemented as in C

 i.x = i.x + u.x;
 i.y = i.y + u.y;
...

and C then doing the appropriate implicit conversions.

So yes, OpenCL doesn't specify implicit conversions and 6.4 suggests that
components are promoted as to C rules which means the current C implementation
matches neither.

Note changing the C frontend can change operation outcome.  IIRC we at
some point
decided to allow implicit sign conversions (we don't implement
convert_VECTOR_TYPE
nor clangs convert_vector).

Richard.

> Alexander

Re: A problem with field decl offsets in newly minted types

[Richard Biener via Gcc]

On Fri, Jan 1, 2021 at 10:16 PM Gary Oblock via Gcc  wrote:
>
> The offsets seem to actually be created. However,
> they are almost immediately are being deleted.

Use a watchpoint to see where.

> Any ideas what's going on? Has some kind
> of memory management gizmo gone awry?
>
> Gary
>
> PS For anybody who has been following my travails with the instance 
> interleaving structure
> reorganization optimization, this is occurring
> with the Mcf sources from SPEC17.
>
> 
> From: Gary Oblock 
> Sent: Wednesday, December 30, 2020 11:00 PM
> To: gcc@gcc.gnu.org 
> Subject: A problem with field decl offsets in newly minted types
>
> I'm having some grief with creating/using some modified types.
>
> I problem occurs in tree-ssa-sccvn.c when some code tries
> to take a DECL_FIELD_OFFSET and unfortuenately gets a null
> that causes a crash.
>
> So, I traced this back the to types I created. Note, the method I used
> has seemed to be fairly robust (some other engineers in our China
> group even successfully copied it for thier own optimization.)
> However, the DECL_FIELD_OFFSET offset is definitely null for
> the fields which I created in the new versions of the types.
>
> Here is what I'm doing.
>
> tree type_prime = lang_hooks.types.make_type (RECORD_TYPE);
>
> const char *base_type_name =
>   identifier_to_locale ( IDENTIFIER_POINTER ( TYPE_NAME ( type)));
> size_t len = strlen ( MY_PREFIX) + strlen ( base_type_name);
> char *rec_name = ( char*)alloca ( len + 1);
> strcpy ( rec_name, MY_PREFIX);
> strcat ( rec_name, base_type_name);
>
> TYPE_NAME ( reorg_type_prime) = get_identifier ( rec_name);
>
> tree field;
> tree new_fields = NULL;
> for ( field = TYPE_FIELDS ( type); field; field = DECL_CHAIN ( field))
>   {
> // Probably useful in creating the new field type.
> tree old_fld_type = TREE_TYPE ( field);
>
> // Whatever you want the new field type to be
> tree new_fld_type = ...;
> tree new_decl =
>   build_decl ( DECL_SOURCE_LOCATION (field),
>   FIELD_DECL, DECL_NAME (field), new_fld_type);
>  DECL_CONTEXT ( new_decl) = type_prime;
>  layout_decl ( new_decl, 0);
>  DECL_CHAIN ( new_decl) = new_fields;
>  new_fields = new_decl;
>   }
>
> TYPE_FIELDS ( type_prime) = nreverse ( new_fields);
> layout_type ( type_prime);
>
> Note, when I change any declaration to have a modified type
> I run relayout_decl on them.
>
> If somebody could please tell what bit I'm missing or what I'm doing
> wrong I'd really appreciate it. Looking at the code in layout_type,
> it should be setting the decl field offsets with place_field and I
> don't have a clue what's going on.
>
> Thanks,
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.
>

Re: Google GSOC Idea

[Martin Jambor]

Hi,

On Sun, Dec 27 2020, Alper G. via Gcc wrote:
> Hello, I am waiting for your suggestions and evaluations about an idea that
> I am thinking about applying to this year's event of google gsoc. In short,
> I can say about myself that I am an engineering student and worked on
> compilers as well as several different fields. Nowadays, we see that
> scripting languages such as javascript / typescript are more than just a
> client-side language in the browser. In order to develop applications on
> desktop and mobile devices, there are alternatives such as electron that
> contain chromium and nodejs, have multi-disk-size requirements and cannot
> be packaged statically before runtime, such as react-native. In order to
> overcome such problems, it is necessary to create the ahead-of-time
> compilation, which we are familiar with such as c / c ++, according to this
> syntax and standards, and to call the graphics libraries and system calls
> directly from within js. Therefore, I want to create a subset of gcc that
> can be statically compiled and contains the ecmascript standards required
> to run common js frameworks native. What are your comments on this
> idea?

I'm afraid I don't understand it at all.  Making GCC "run common js
frameworks" makes very little sense to me.  Are you proposing some kind
of JavaScript Front-end (which is not a JIT)?

> What can we say about the acceptability for gsoc?

Well, unfortunately I can say only that I do not understand it.  If it
is the JavaScript Front-end, the project would too big for a GSoC, by
orders of magnitude, even if severely reduced in scope.

Martin

Re: Copyright assignment for Rust-GCC

[Jeff Law via Gcc]

On 1/4/21 3:28 AM, Nala Ginrut via Gcc wrote:
> Hi Folks!
> This mail is about the development of Rust frontend of GCC.
>
> To avoid misunderstanding, please let me introduce Rust-GCC briefly.
> In 2013, Philip Herron had announced the project in GCC mailing-list:
> https://gcc.gnu.org/legacy-ml/gcc/2013-12/msg00017.html
> In 2019, @SimplyTheOther had contributed the almost complete parser and
> AST.
> And I helped to do some trival work to make it work with the latest GCC
> at that time.
> Of course there're more contributors that I can't mention one by one.
> At that time, a small community of Rust-GCC had formed. We're interested
> in continuing it till it can be merged into GCC.
> https://github.com/Rust-GCC/gccrs
> So this is the brief history.
>
> Now we have a question, when should we assign copyright paper for GNU?
As soon as possible.

> Last time I assigned the copyright paper, I noticed that the paper
> mentioned the project name. But Rust-GCC hasn't been recogonized by GCC
> community yet, so I'm not sure if it's the correct time to consider this
> issue.
ISTM that the assignment should be for "gcc" since presumably the final
goal is to get the Rust front-end integrated into GCC, right?

jeff

Re: Security vulnerabilities affects core API authorization of gnu.org

[Jeff Law via Gcc]

On 1/4/21 3:23 AM, Salah Mosbah via Gcc wrote:
> Hi Janus,
>
> How can I report some high impact security vulnerabilities that I have
> found on gnu.org
> web app?
>
> Also, does gnu.org has a bug bounty program or reporting bugs reward policy?
>
> The vulnerabilities that I have found affects the core API of gnu.org which
> allows unauthorized users to get access to other user's data that they
> don't have access to it.
For gnu.org you'd need to contact the administrators of that domain,
which presumably you find contact information for on www.gnu.org.

If it's a problem with gcc.gnu.org, then the details should be sent to
overse...@gcc.gnu.org

Jeff

Re: Copyright assignment for Rust-GCC

[David Edelsohn via Gcc]

On Mon, Jan 4, 2021 at 5:29 AM Nala Ginrut via Gcc  wrote:
>
> Hi Folks!
> This mail is about the development of Rust frontend of GCC.
>
> To avoid misunderstanding, please let me introduce Rust-GCC briefly.
> In 2013, Philip Herron had announced the project in GCC mailing-list:
> https://gcc.gnu.org/legacy-ml/gcc/2013-12/msg00017.html
> In 2019, @SimplyTheOther had contributed the almost complete parser and
> AST.
> And I helped to do some trivial work to make it work with the latest GCC
> at that time.
> Of course there are more contributors that I can't mention one by one.
> At that time, a small community of Rust-GCC had formed. We're interested
> in continuing it till it can be merged into GCC.
> https://github.com/Rust-GCC/gccrs
> So this is the brief history.
>
> Now we have a question, when should we assign copyright paper for GNU?
> Last time I assigned the copyright paper, I noticed that the paper
> mentioned the project name. But Rust-GCC hasn't been recognized by GCC
> community yet, so I'm not sure if it's the correct time to consider this
> issue.
>
> Comments are welcome.

As Jeff wrote, the assignment is for the GNU Compiler Collection (GCC)
project, not for specific languages.  One does /not/ submit separate
assignments for GNU Fortran, GNU C++, GNU Go, GNU Ada, GNU Modula2,
etc.

Please have all of the developers start the FSF copyright assignment
process now.

Thanks, David

[no subject]

[Brian Campbell via Gcc]

gengtype and automatically generated files

[Bill Schmidt via Gcc]

Hi!  I'm attempting to do something that may not have been done before, 
so I'm looking for advice, or a pointer to where, in fact, it has been 
done before. :)


I'm automatically generating a back-end header file that declares some 
structures that include trees, and a bunch of global variables that are 
also trees.  I've marked everything up appropriately, but I also need to 
teach the garbage collector that this file exists.


Most back-end files are automatically scanned by gengtype.  Per the 
documentation, anything that isn't handled automatically needs to be 
added to target_gtfiles in config.gcc.  However, I can't come up with a 
syntax for describing a file in the gcc/ build subdirectory.  Some 
places in config.gcc allow "./filename" as shorthand for "filename" 
being in the current build directory, but that doesn't seem to work for 
adding something to gtyp-input.list.


Any recommendations on what I should do next?  At the moment it looks 
like I might have to hack on gengtype to invent a way to scan a file in 
the build directory, but I have a mild amount of hope that someone has 
solved this before.  Thanks for any help!


Bill

Re: Security vulnerabilities affects core API authorization of gnu.org

[Salah Mosbah via Gcc]

Hi Jeff,

Does gnu.org has a bug bounty program or reporting bugs reward policy?

On Mon, Jan 4, 2021 at 6:06 PM Jeff Law  wrote:

>
>
> On 1/4/21 3:23 AM, Salah Mosbah via Gcc wrote:
> > Hi Janus,
> >
> > How can I report some high impact security vulnerabilities that I have
> > found on gnu.org
> > web app?
> >
> > Also, does gnu.org has a bug bounty program or reporting bugs reward
> policy?
> >
> > The vulnerabilities that I have found affects the core API of gnu.org
> which
> > allows unauthorized users to get access to other user's data that they
> > don't have access to it.
> For gnu.org you'd need to contact the administrators of that domain,
> which presumably you find contact information for on www.gnu.org.
>
> If it's a problem with gcc.gnu.org, then the details should be sent to
> overse...@gcc.gnu.org
>
> Jeff
>
>

Re: Security vulnerabilities affects core API authorization of gnu.org

[Jeff Law via Gcc]

On 1/4/21 10:40 AM, Salah Mosbah wrote:
> Hi Jeff,
>
> Does gnu.org  has a bug bounty program or reporting
> bugs reward policy?
I have no idea.
jeff
>

Re: Security vulnerabilities affects core API authorization of gnu.org

[Frank Ch. Eigler via Gcc]

Hi -

> Does gnu.org has a bug bounty program or reporting bugs reward policy?

You are not talking to gnu.org, you are talking to gcc.gnu.org admins.
Maybe see webmast...@gnu.org.
I am not aware of any sort of bug bounty in either site.

- FChE

Re: gengtype and automatically generated files

[Jeff Law via Gcc]

On 1/4/21 10:40 AM, Bill Schmidt via Gcc wrote:
> Hi!  I'm attempting to do something that may not have been done
> before, so I'm looking for advice, or a pointer to where, in fact, it
> has been done before. :)
>
> I'm automatically generating a back-end header file that declares some
> structures that include trees, and a bunch of global variables that
> are also trees.  I've marked everything up appropriately, but I also
> need to teach the garbage collector that this file exists.
>
> Most back-end files are automatically scanned by gengtype.  Per the
> documentation, anything that isn't handled automatically needs to be
> added to target_gtfiles in config.gcc.  However, I can't come up with
> a syntax for describing a file in the gcc/ build subdirectory.  Some
> places in config.gcc allow "./filename" as shorthand for "filename"
> being in the current build directory, but that doesn't seem to work
> for adding something to gtyp-input.list.
>
> Any recommendations on what I should do next?  At the moment it looks
> like I might have to hack on gengtype to invent a way to scan a file
> in the build directory, but I have a mild amount of hope that someone
> has solved this before.  Thanks for any help!
Yea, I don't see any indication this has ever been done before.  I'm a
bit surprised that ./ doesn't work since gengtype runs from
the build directory and has to reference things in the source directory
and ./ would seem to naturally reference the build directory

Jeff

Re: gengtype and automatically generated files

[Bill Schmidt via Gcc]

Actually, the "./filename" syntax works fine.  I was missing a 
dependency in my t-rs6000 to make the header file appear available.


Sorry for the noise!

Bill

On 1/4/21 11:40 AM, Bill Schmidt wrote:
Hi! I'm attempting to do something that may not have been done before, 
so I'm looking for advice, or a pointer to where, in fact, it has been 
done before. :)


I'm automatically generating a back-end header file that declares some 
structures that include trees, and a bunch of global variables that 
are also trees.  I've marked everything up appropriately, but I also 
need to teach the garbage collector that this file exists.


Most back-end files are automatically scanned by gengtype.  Per the 
documentation, anything that isn't handled automatically needs to be 
added to target_gtfiles in config.gcc.  However, I can't come up with 
a syntax for describing a file in the gcc/ build subdirectory.  Some 
places in config.gcc allow "./filename" as shorthand for "filename" 
being in the current build directory, but that doesn't seem to work 
for adding something to gtyp-input.list.


Any recommendations on what I should do next?  At the moment it looks 
like I might have to hack on gengtype to invent a way to scan a file 
in the build directory, but I have a mild amount of hope that someone 
has solved this before.  Thanks for any help!


Bill

Re: Copyright assignment for Rust-GCC

[Eric Gallager via Gcc]

On Mon, Jan 4, 2021 at 11:13 AM David Edelsohn via Gcc 
wrote:

> On Mon, Jan 4, 2021 at 5:29 AM Nala Ginrut via Gcc 
> wrote:
> >
> > Hi Folks!
> > This mail is about the development of Rust frontend of GCC.
> >
> > To avoid misunderstanding, please let me introduce Rust-GCC briefly.
> > In 2013, Philip Herron had announced the project in GCC mailing-list:
> > https://gcc.gnu.org/legacy-ml/gcc/2013-12/msg00017.html
> > In 2019, @SimplyTheOther had contributed the almost complete parser and
> > AST.
> > And I helped to do some trivial work to make it work with the latest GCC
> > at that time.
> > Of course there are more contributors that I can't mention one by one.
> > At that time, a small community of Rust-GCC had formed. We're interested
> > in continuing it till it can be merged into GCC.
> > https://github.com/Rust-GCC/gccrs
> > So this is the brief history.
> >
> > Now we have a question, when should we assign copyright paper for GNU?
> > Last time I assigned the copyright paper, I noticed that the paper
> > mentioned the project name. But Rust-GCC hasn't been recognized by GCC
> > community yet, so I'm not sure if it's the correct time to consider this
> > issue.
> >
> > Comments are welcome.
>
> As Jeff wrote, the assignment is for the GNU Compiler Collection (GCC)
> project, not for specific languages.  One does /not/ submit separate
> assignments for GNU Fortran, GNU C++, GNU Go, GNU Ada, GNU Modula2,
> etc.
>
>
Speaking of Modula2, has that frontend made it into mainline GCC yet? I see
there was a bugzilla component for it added, but I don't remember seeing
anything about it in the changes.html file for any existing releases...


> Please have all of the developers start the FSF copyright assignment
> process now.
>
> Thanks, David
>

Query about compatibility

[Chirumamilla Ganesh via Gcc]

Does M1 MacBooks support GCC compilers ,if not will M1 MacBooks ever get
compatibility of GCC compilers