git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* [Question] Documenting platform implications on CVE to git
@ 2017-10-06 13:28 Randall S. Becker
  2017-10-06 22:50 ` Jonathan Nieder
  0 siblings, 1 reply; 5+ messages in thread
From: Randall S. Becker @ 2017-10-06 13:28 UTC (permalink / raw)
  To: git

Hi All,

I wonder whether there is some mechanism for providing official responses
from platform ports relating to security CVE reports, like CVE-2017-14867.
For example, the Perl implementation on HPE NonStop does not include the SCM
module so commands relating cvsserver may not be available - one thing to be
verified so is a question #1. But the real question (#2) is: where would one
most appropriately document issues like this to be consistent with other
platform responses relating to git?

Thanks,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(211288444200000000) 
-- In my real life, I talk too much.




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Question] Documenting platform implications on CVE to git
  2017-10-06 13:28 [Question] Documenting platform implications on CVE to git Randall S. Becker
@ 2017-10-06 22:50 ` Jonathan Nieder
  2017-10-06 23:34   ` Randall S. Becker
  0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Nieder @ 2017-10-06 22:50 UTC (permalink / raw)
  To: Randall S. Becker; +Cc: git

Hi Randall,

Randall S. Becker wrote:

> I wonder whether there is some mechanism for providing official responses
> from platform ports relating to security CVE reports, like CVE-2017-14867.

This question is too abstract for me.  Can you say more concretely
what you are trying to do?

E.g. are you asking how you would communicate to users of your port
that CVE-2017-14867 does not apply to them?  Or are you asking where
to start a conversation about who a bug applies to?  Or something
else?

Thanks,
Jonathan

> For example, the Perl implementation on HPE NonStop does not include the SCM
> module so commands relating cvsserver may not be available - one thing to be
> verified so is a question #1. But the real question (#2) is: where would one
> most appropriately document issues like this to be consistent with other
> platform responses relating to git?
>
> Thanks,
> Randall
>
> -- Brief whoami: NonStop&UNIX developer since approximately
> UNIX(421664400)/NonStop(211288444200000000)
> -- In my real life, I talk too much.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: [Question] Documenting platform implications on CVE to git
  2017-10-06 22:50 ` Jonathan Nieder
@ 2017-10-06 23:34   ` Randall S. Becker
  2017-10-06 23:44     ` Jonathan Nieder
  0 siblings, 1 reply; 5+ messages in thread
From: Randall S. Becker @ 2017-10-06 23:34 UTC (permalink / raw)
  To: 'Jonathan Nieder'; +Cc: git

-----Original Message-----
On October 6, 2017 6:51 PM, Jonathan Nieder wrote
>Randall S. Becker wrote:
>> I wonder whether there is some mechanism for providing official 
>> responses from platform ports relating to security CVE reports, like
CVE-2017-14867.

>This question is too abstract for me.  Can you say more concretely what you
are trying to do?
>E.g. are you asking how you would communicate to users of your port that
CVE-2017-14867
?does not apply to them?  Or are you asking where to start a conversation
about
>who a bug applies to?  Or something else?

The first one, mostly. When looking at CVE-2017-14867, there are places like
https://nvd.nist.gov/vuln/detail/CVE-2017-14867 where the issue is
discussed. It provides hyperlinks to various platform discussions.
Unfortunately for me, I am not an HPE employee - and even if I was, there is
no specific site where I can publicly discuss the vulnerability. I'm looking
to the group here for advice on how to get the word out that it does not
appear to apply to the HPE NonStop Git port. The question of where to best
do that for any CVE pertaining to git as applicable to the NonStop Port is
question #1.

Question #2 - probably more relevant to the specific issue and this group -
is whether the vulnerability is contained to Git's use of Perl SCM and since
NonStop's Perl does not support SCM, the vulnerability may not be relevant,
but I'm not really enough of a Perl guru to make that determination.

Cheers,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(211288444200000000) 
-- In my real life, I talk too much.




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Question] Documenting platform implications on CVE to git
  2017-10-06 23:34   ` Randall S. Becker
@ 2017-10-06 23:44     ` Jonathan Nieder
  2017-10-07  0:04       ` Randall S. Becker
  0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Nieder @ 2017-10-06 23:44 UTC (permalink / raw)
  To: Randall S. Becker; +Cc: git

Hi,

Randall S. Becker wrote:

> The first one, mostly. When looking at CVE-2017-14867, there are places like
> https://nvd.nist.gov/vuln/detail/CVE-2017-14867 where the issue is
> discussed. It provides hyperlinks to various platform discussions.
> Unfortunately for me, I am not an HPE employee - and even if I was, there is
> no specific site where I can publicly discuss the vulnerability. I'm looking
> to the group here for advice on how to get the word out that it does not
> appear to apply to the HPE NonStop Git port. The question of where to best
> do that for any CVE pertaining to git as applicable to the NonStop Port is
> question #1.

How do people find out about the HPE NonStop Git port?  Where is it
distributed?  Does that distribution point allow you to publish
release notes or other documentation?

Do you have a web page?  That's another place you can publish
information.  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14867
links to lots of resources that are not from the Git project.

The oss-security list <http://www.openwall.com/lists/oss-security/>
allows anyone to participate.  It is a place that people often
collaborate to figure out the impact of a published vulnerability, how
to mitigate it, etc.  There are other similar mailing lists elsewhere,
too.

> Question #2 - probably more relevant to the specific issue and this group -
> is whether the vulnerability is contained to Git's use of Perl SCM and since
> NonStop's Perl does not support SCM, the vulnerability may not be relevant,
> but I'm not really enough of a Perl guru to make that determination.

What is Perl SCM?  I don't know what you're talking about.

Thanks,
Jonathan

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: [Question] Documenting platform implications on CVE to git
  2017-10-06 23:44     ` Jonathan Nieder
@ 2017-10-07  0:04       ` Randall S. Becker
  0 siblings, 0 replies; 5+ messages in thread
From: Randall S. Becker @ 2017-10-07  0:04 UTC (permalink / raw)
  To: 'Jonathan Nieder'; +Cc: git

-----Original Message-----
On October 6, 2017 7:45 PM  Jonathan Nieder wrote: Cc: git@vger.kernel.org
>Randall S. Becker wrote:
>> The first one, mostly. When looking at CVE-2017-14867, there are 
>> places like
>> https://nvd.nist.gov/vuln/detail/CVE-2017-14867 where the issue is 
>> discussed. It provides hyperlinks to various platform discussions.
>> Unfortunately for me, I am not an HPE employee - and even if I was, 
>> there is no specific site where I can publicly discuss the 
>> vulnerability. I'm looking to the group here for advice on how to get 
>> the word out that it does not appear to apply to the HPE NonStop Git 
>> port. The question of where to best do that for any CVE pertaining to 
>> git as applicable to the NonStop Port is question #1.

>How do people find out about the HPE NonStop Git port?  Where is it distributed? 

It is available at http://ituglib.connect-community.org/apps/Ituglib/SrchOpenSrcLib.jsf but we have limited abilities to modify anything but that page. There is a brief release note but nothing sufficient to have a discussion. 

>Does that distribution point allow you to publish release notes or other documentation?

Not enough for what I think are our needs.
 
> Do you have a web page?  That's another place you can publish information. 
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14867
> links to lots of resources that are not from the Git project.
> The oss-security list <http://www.openwall.com/lists/oss-security/>
> allows anyone to participate.  It is a place that people often collaborate to figure out the impact of a published
> vulnerability, how to mitigate it, etc.  There are other similar mailing lists elsewhere, too.

Thanks, I'll take these to the team.

>> Question #2 - probably more relevant to the specific issue and this 
>> group - is whether the vulnerability is contained to Git's use of Perl 
>> SCM and since NonStop's Perl does not support SCM, the vulnerability 
>> may not be relevant, but I'm not really enough of a Perl guru to make that determination.

>What is Perl SCM?  I don't know what you're talking about.

Base Perl does not have a lot of capability beyond a simple interpreter. The CPAN project,  https://www.cpan.org/, provides implementations of useful modules, including Source Code Management (SCM) modules that enable things like cvsserver AFAIK, and Mercurial to run. Without it (being the ability to arbitrarily add CPAN modules, which is an issue on NonStop), Perl tends to be a bit handcuffed and blindfolded. 😉

Thanks for the suggestions,
Randall


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-10-07  0:04 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-06 13:28 [Question] Documenting platform implications on CVE to git Randall S. Becker
2017-10-06 22:50 ` Jonathan Nieder
2017-10-06 23:34   ` Randall S. Becker
2017-10-06 23:44     ` Jonathan Nieder
2017-10-07  0:04       ` Randall S. Becker

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).