[Python-Dev] Need help on security vulnerability zlib 1.2.11

[Prasad, PCRaghavendra]

Hi All,

We are facing some issue with the zlib package 1.2.11. Recently there was a 
vulnerability in zlib and we had to upgrade to 1.2.12 on all supported platforms
We did that in all platforms including windows, python39.dll is now showing 
1.2.12 but the problem is we use pyinstaller to generate application exe.
This exe is still referring to 1.2.11 we tried lot of things to find how it is 
linking to 1.2.11, there is no line of sight on this.

Can any one please provide some input on this

Thanks,
Raghu


Internal Use - Confidential
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RMWN43WHALFSEWOYQUMT63YFSBPL3MPQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: GSOC

[Brett Cannon]

On Tue, Apr 19, 2022 at 7:14 AM Jean Abou Samra  wrote:

> Hi,
>
> Le 19/04/2022 à 01:56, faresbaso...@gmail.com a écrit :
> > i want to contribute in mailman which is a sub-org under python software
>
>
> Where do you see this? I can't find it under github.com/python.
> The repository seems to be living here:
>
> https://gitlab.com/mailman/mailman


GSoC has historically organized Python-based projects too small to have
their own org under the Python Software Foundation (
https://summerofcode.withgoogle.com/programs/2022/organizations/python-software-foundation),
so it has nothing to do with where a repo lives. You can see Mailman listed
at https://python-gsoc.org/ideas.html .

-Brett


>
>
> Wait, actually, I see a merge request from you there. Did
> you find it in the meantime?
>
>
> > in  GSOC
> > there's 2 templates to submit i want to know which template is the
> correct one,
> > the one in mailman's site or the one in python's site
>
>
>
> Whatever infrastructure Mailman may share with Python, it is an
> entirely separate project, so this will almost certainly be
> the template from the Mailman project.
>
> Best,
> Jean
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/AREDYQMSWMDLQK77LIYUHWDVHLER6WOG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QF6V2MT7A42ASXHZ2L6RPT4LCXA2Y4AK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

[Victor Stinner]

6 months ago, I wrote a different document based on HPy Manifesto:

"PEP: Taking the Python C API to the Next Level"
https://mail.python.org/archives/list/python-dev@python.org/message/RA7Q4JAUEITJBOUAXFEJKRRM2RR3QSZI/

Victor

On Mon, Apr 4, 2022 at 5:20 PM Petr Viktorin  wrote:
>
> On 03. 02. 22 1:40, Guido van Rossum wrote:
> [...]
> >
> > I understand the CPython is stuck supporting the de-facto standard C API
> > for a long time. But unless we pick a "north star" (as people call it
> > nowadays) of what we want to support in say 5-10 years, the situation
> > will never improve.
> >
> > My point about "getting one chance to get it right in the next decade"
> > is that we have to pick that north star, so we can tell users which
> > horse to bet on. If the north star we pick is HPy, things will be clear.
> > If it is evolving the C API things will also be clear. But I think we
> > have to pick one, and stick to it so users (i.e., package
> > maintainers/developers) have clarity.
>
> A few months later, here's a draft of a “north star” document.
> Is this close to what you had in mind?
>
> https://docs.google.com/document/d/1lrvx-ujHOCuiuqH71L1-nBQFHreI8jsXC966AFu9Mqc/edit#
>
>
> Please comment (here or there) as appropriate :)
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/DUWBMGLEYP6VFFT7OMMA6KJNJKTEY47R/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NMMFZSCOEKQDCGUAVIOWV3NYZ5M6NQMJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [External] : Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

[Petr Viktorin]

On 06. 04. 22 9:23, Tim Felgentreff wrote:

Hi,

(I briefly commented also on the doc regarding this)

I’m probably misinterpreting the exact goals. I read “stable ABI for 
everyone” and I’m thinking “what needs to happen to stay binary 
compatible and working for a couple of decades at least”. 


Well, the doc is more down to the ground than this thread can be :)

If that were 
the goal, I think the ideas around HPy’s handles and it’s usage of a 
context to get access to function pointers are most important, since 
that will ensure that new APIs can be added and old ones removed without 
breaking ABI. (This is very similar to how e.g. libraries like SDL deal 
with the problem that distributors want to update the SDL library and 
have it still work with 10 year old proprietary games).


In particular, even things like slots in types need to be opaque. An 
optimizing runtime may want to use varying layouts for both types and 
objects - allowing direct access into any runtime structures prevents 
that. Exposed structures should not be used for any runtime objects, 
only as specs for construction of those runtime objects.


With Python's current general API backwards compatibility policy (PEP 
387), it wouldn't make much sense to make ABI guarantees that strong. In 
reality you're likely to get DeprecationWarnings and runtime exceptions, 
and will need to recompile extensions well before decades+-scale ABI 
incompatibilities hit you.


IIUC, adopting HPy would break API: adding a context argument to all 
functions would would be so massive a change, it'd be easier to just 
call that HPy rather than Python C-API. And the doc I shared is for the 
C-API.
(Perhaps CPython can even move to HPy and implement C-API as a veener on 
top -- but I don't think the original C-API can go away in our lifetimes.)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZHHLESVGP6BHNK2UHJTPY34GVWJCV3KP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: GSOC

[Jean Abou Samra]

Hi,

Le 19/04/2022 à 01:56, faresbaso...@gmail.com a écrit :

i want to contribute in mailman which is a sub-org under python software



Where do you see this? I can't find it under github.com/python.
The repository seems to be living here:

https://gitlab.com/mailman/mailman

Wait, actually, I see a merge request from you there. Did
you find it in the meantime?



in  GSOC
there's 2 templates to submit i want to know which template is the correct one,
the one in mailman's site or the one in python's site




Whatever infrastructure Mailman may share with Python, it is an
entirely separate project, so this will almost certainly be
the template from the Mailman project.

Best,
Jean

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AREDYQMSWMDLQK77LIYUHWDVHLER6WOG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Updating inspect APIs

[Petr Viktorin]

On 17. 04. 22 19:20, Pablo Galindo Salgado wrote:

Hi,

We are currently debating in gh-88116 
(https://github.com/python/cpython/issues/88116 
)
what's the best way forward to update the APIs in the inspect module to 
include the new position information.


These APIs are inspect.getframeinfo, inspect.getouterframes, 
inspect.getinnerframes, inspect.stack and inspect.trace.


The problem is that these APIs return a named tuple that now needs to 
include several new attributes (or one 4 tuple for
the positions). Being named tuples, if we add a new attribute, existing 
unpackings of the tuple will now fail because there
are more elements or the elements are in different positions. Also, it 
will be quite weird to add the new attributes at the

end but leave the line number at the beginning.

What's the best way to proceed here? The suggested way is to create a 
namedtuple subclass that adds the extra attributes
but doesn't allow indexed access to it (there is a precedent to this in 
how we handled updating os.stat_result). I personally
find this quite confusing but it certainly works. There may be other 
options.


IMO, that is the way to do it -- PyStructSequence.


I'd then discourage indexed access. It is indeed confusing, but that's 
OK for something that's only there for backwards compatibility:

- users who are confused should read the docs and update their code.
- core devs can hopefully read a comment nearby and not be confused.

(And I don't think it's worth deprecating and removing indexed access -- 
there's no reason to break code that works just because there's now a 
better API.)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YX2F3U5ALP6XBPZOTNITCLBGFFWTIWKK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do you ever use ceval.c's LLTRACE feature?

[Victor Stinner]

Hi,

In 2017, I proposed to document the feature, but nobody was volunteer
to write the doc (issue still open):
https://bugs.python.org/issue25571

I added a bare minimum mention of this feature in the "Python Debug
Build" documentation:
https://docs.python.org/dev/using/configure.html#python-debug-build

A bug was fixed in 2018, so it has at least one user :-)
https://bugs.python.org/issue34113

In 2017, adding an API to trace instructions with sys.settrace() was
discussed, but the idea got rejected:

* https://bugs.python.org/issue29400
* https://mail.python.org/pipermail/python-dev/2017-September/149632.html

IMO it would be more flexible than the current "lltrace"
implementation which hardcode writing bytecode into C stdout stream
which is not convenient and cannot be easily redirected. I have no
idea if it would be possible to provide an *efficient* implementation
of such hook in ceval.c, even if it's only implemented in debug build.

Victor
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/M6R6EWL2FS5SZC4A3ZDIPZH2LI6G4TFO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 670 – Convert macros to functions in the Python C API

[Victor Stinner]

PEP 670 – Convert macros to functions in the Python C API:
https://peps.python.org/pep-0670/

That's great! Thanks to everyone who was involved in PEP 670: the
feedback helped Erlend and me to write a better PEP. It was a long
journey, Erlend started the first discussion about macros in March
2021!

https://discuss.python.org/t/what-to-do-with-unsafe-macros/7771

Victor

On Tue, Apr 12, 2022 at 11:22 AM Petr Viktorin  wrote:
>
> Hello,
> The Steering Council is **Accepting** the latest iteration of PEP 670:
> Convert macros to functions in the Python C API. Congratulations!
>
>
> - Petr, on behalf of the Steering Council



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YK2MOWYS3IOL3BQ3DBG7G7YF3MH7BBQM/
Code of Conduct: http://python.org/psf/codeofconduct/