Re: Report a potential risk of secret leakage in project(mpi4py)

[Lisandro Dalcin]

CCing mpi4py public mailing list for full disclosure.

The supposedly secret leaks you reported to me are obvious false positives. Whatever automated tool you are using to perform these analyses in mass, the tool is complaining that some C source code in my project has local variables with prefixes "KEYVAL" and "keyval", and these variables contain absolutely no secrets. Obviously, no human has performed any kind verification/validation on the results of such automated scanning. The human verification process has just been done by me after your (likely automated?) email, in the benefit of your project, and at the expense of my time.

I kindly request for the mpi4py project to be removed from your listing of projects affected by security issues, and not mention it in any way in any future report you publish.

Best regards,

On Wed, 4 Sept 2024 at 15:36, <jiawe...@seu.edu.cn> wrote:

Dear developers of the project(mpi4py),

We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem.

In our analysis, we identified potential secret leakage risks in your project, mpi4py.

We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data:

{   'file': '',                 #The file containing the secret
                                            #The project name, version or commit_hash may be reflected in the file path
    'line_start': 1,    #location: Start line of the secret
    'line_end': 28,             #location: End line of the secret
    'col_start': 1,             #location: Start column of the secret
    'col_end': 1,               #location: End column of the secret
    'index_start': 0,   #location: Start index of the secret
    'index_end': 1675,  #location: End index of the secret
    ......and smoe information about the package_name、version......
}


Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy.

Some advise:

1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately.
2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds.

Best regards,

--

Lisandro Dalcin
============
Senior Research Scientist

Advanced Algorithm and Numerical Simulations Laboratory (AANSLab)

Computer, Electrical and Mathematical Science and Engineering (CEMSE)

King Abdullah University of Science and Technology (KAUST)

https://cemse.kaust.edu.sa/aanslab

[Yury V. Zaytsev]

Sadly, an obvious result of "publish or perish" incentives. I routinely get this kind of garbage for the projects I maintain, too. Maybe we should talk to Jiawei Zhou's supervisor and explain the kind of damage he is doing to the reputation of Southeast University.

> --
> You received this message because you are subscribed to the Google Groups "mpi4py" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mpi4py+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mpi4py/CAEcYPwCoedQsphEpMSE6-HoC7wrAOdMENFtmrpfh65Q4_-CRYA%40mail.gmail.com.

[Lisandro Dalcin]

On Thu, 5 Sept 2024 at 11:18, Yury V. Zaytsev <yu...@shurup.com> wrote:

Hi, Yury, long time not see...

Sadly, an obvious result of "publish or perish" incentives. I routinely get this kind of garbage for the projects I maintain, too.

Damn, I'm feeling silly... This was my first time! I didn't know this was commonplace.

 

Maybe we should talk to Jiawei Zhou's supervisor and explain the kind of damage he is doing to the reputation of Southeast University.

You are assuming the supervisor is not the actual root of the problem 😉... Unless I got wrong who you were referring to by "he".

Warm regards,

[Yves Revaz]

Hi Lisandro,

Thanks a lot for having posted this information.

Very useful to be aware of those scanning techniques that can blindly affect the reputation of projects.

Best,

yves revaz

--
You received this message because you are subscribed to the Google Groups "mpi4py" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mpi4py+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mpi4py/CAEcYPwDaApOjoKLfaJtj19HGSkCg7UCt7Q_aDMbvXiQ0sPgtSg%40mail.gmail.com.

-- 
---------------------------------------------------------------------
  Dr. Yves Revaz (MER)
  Laboratory of Astrophysics (LASTRO)
  Ecole Polytechnique Fédérale de Lausanne (EPFL)
  Observatoire de Sauverny     Tel : +41 22 379 24 28
  51. Ch. Pegasi               Fax : +41 22 379 22 05
  1290 Sauverny             e-mail : Yves....@epfl.ch
  SWITZERLAND                  Web : http://people.epfl.ch/yves.revaz
---------------------------------------------------------------------

[Yury V. Zaytsev]

Hi Lisandro,

> Hi, Yury, long time not see...

Nice to hear from you too! Unfortunately, I haven't had a chance to do any serious performance work in Python in the last few years, so I'm slowly dropping out of the mpi4py / Cython / NumPy | SciPy club. I hope you are doing well in your area! If the Kingdom gets really desperate to allocate the surplus funds, I might be up for grabs next year ;-)

> Damn, I'm feeling silly... This was my first time! I didn't know this was commonplace.

Well, so far I have been mostly receiving junk mail about participating research surveys for influential open source developers on the basis of my contributions (hey, I’m an influencer, baby! Impressive 29 followers on GitHub!) regarding the tooling, project organization and such or automated defect reports, which upon closer inspection always turn out to be obvious false positives.

Automated false positive security reports are indeed something new, so you are definitely NOT silly. I guess I would have reacted the same way had I not been desensetized by folks posting on oss-security and filing CVEs for non-security issues just to build up an 1337 h4x0r rep (same problem here: wrong incentives - you can cash in significantly more if you have enough CVEs to your name).

> You are assuming the supervisor is not the actual root of the problem 😉... Unless I got wrong who you were referring to by "he”.

The root of the problem is the business model of writing crappy meta-reviews or survey research studies, like the ones I used to shoot down for Computer Standards & Interfaces.

You run some analysis tool and auto-spam a representative number of projects for the study, or get enough open source contributors to respond to your survey so that you have enough material to write a sloppy paper, the journal gets a few thousand grands for publishing, and you get a publication in an IF > 2 journal, which in turn can be used to bring in grant money to perpetuate the system.

Sounds fantastic, except for the waste it creates. But then again, there are worse business models out there, it's just that this one is particularly frustrating because it capitalizes on the abuse of the academic system, which is already in a sad enough state.

Whether the supervisor actually perpetuated it or just left the student to his own devices and he came up with this brilliant idea on his own doesn't really matter. Just wanted to say that there's no point in harassing the student, but you might be able to get the supervisor to stop or actually supervise for fear of getting in trouble with the university administration, which of course would not condone this behavior, at least not officially.

All the best,
Yury