Re: Introduction for GSoC - Darsh

[Darsh Patel]

Greetings Marcus,
Let me put some light on what I'm trying to accomplish here, npm is
basically a dependency manager for NodeJS, it allows users to quickly
install libraries and dependencies for their NodeJS Projects. NPM now
provides 'npm audit' which reports vulnerabilities to the user and also
updates to patched versions of those dependencies with 'npm audit --fix',
I've attached a sample report for reference.
[image: npm_audit.png]
The vulnerability information is mostly crowdsourced from
npmjs.com/advisories 

Now coming back to MacPorts, multiple organizations publish CVEs ( Common
Vulnerabilities and Exposures ) which are linked to CPEs
What are CPEs?
CPE stands for Common Platform Enumeration and is "a standardized method of
describing and identifying classes of applications, operating systems, and
hardware devices present among an enterprise's computing assets"
Currently, the US Government maintains a searchable index of CPEs as a part
of NIST.

SInce CPEs come in a standard format   cpe:/ {part} : {vendor} : {product}
: {version} : {update} : {edition} : {language}
for example, a CPE published
on
1password cpe:/a:agilebits:1password:3.0:-:~~~
Can be used to identify that the package 1password
 is vulnerable ( current
portfile on macports isn't installing the vulnerable pckage )

We can either mirror the database or use the API at nvd.nist.gov to look
for vulnerable ports ( I'd suggest the former ).
Crowdsourcing the data is another way to identify vulnerabilities in
packages, I'd be happy to develop the full stack of a vulnerability
advisory for MacPorts but I believe it would put more pressure on the
maintainers to also moderate the vulnerability advisory.

~Darsh

GSoC web-app query

[DANDAMUDI ROHIT]

Hello everyone!

I am currently pursuing my undergrad in India. As I mentioned my interest to 
work on web-app project before, I went ahead and did some PRs and went through 
all the current issues and got more understanding of the project. I would like 
to draft my application for the same, where should I send my draft for review 
and further discussion.

Regards,
Dandamudi Rohit

Re: Introduction for GSoC - Darsh

[Marcus Calhoun-Lopez]

Greetings Darsh,

We are glad to hear about your interest in the MacPorts project.

I am afraid I do not know much about the npm audit feature (or npm for that 
matter).
How do you propose to determine that a security vulnerability exists?
If a vulnerability is identified, what would your project propose to do about 
it?

As for helping with the build infrastructure, I am afraid others will have to 
chime in with suggestions.

-Marcus

> On Mar 13, 2020, at 11:28 AM, Darsh Patel  wrote:
> 
> Hello everyone! 
>I'm Darsh, I'm 19 and I'm a Computer science undergrad. I'll give a super 
> short introduction in the and talk about my ideas for MacPorts, 
> 
> I'm currently working part-time for a LegalTech Startup ( for free, no 
> obligations per se) as a DevOps and Backend Lead. I've been into tech since a 
> very young age, put on paper ( literally ) by this article in Times of India 
> about a smart home project I built when I was 14. 
> I'm primarily a backend developer, but I'm competent with the rest of the 
> stack too.  I also have a background in CyberSecurity ( I have a CEH 
> Certification too ). Here's my CV in case you want to know more
> 
> My Project idea for GSoC: I'd like to help implement vulnerability scanning 
> and audit for ports, Similar to npm's "audit" feature. I was also looking 
> into writing scripts to help current ports follow better security practices 
> and enforce them. 
> Also, is there a need/plan to change the build infrastructure? I'd love to 
> help with that in any way I can, helping with improving logging / more 
> efficient package builds, etc. 
> 
> I'm all ears for feedback and suggestions for my ideas, 
> 
> Super Excited, 
> Darsh 
> 
> 

Re: gcc won't build i386 with our cctools assembler hack

[Ken Cunningham]

Iain's fix changes the assembly output to succeed if the assembler detected 
during the i386 gcc build is clang, but this is not an on-the-fly change, 
rather a configure-at-build change... so for our purposes, we will still need 
to force the older gas behaviour when gcc is built i386, so gcc will still work 
if clang 5+ is not installed.

I have sorted out how to do that (gcc does not make it trivial to set envvars) 
and it fixes the i386 builds if clang 5+ is installed.

As usual, I'll be testing it for a while prior to pushing it. Anyone interested 
in helping please volunteer and you can run the test suite.

This may now allow libgcc to move up on several systems as well, as it was only 
the i386 build holding it back, however there are reports of bootstrapping 
troubles where the current  gcc9/libgcc9 might no longer build with 
gcc-4.2...so there's that to review.

K