Re: Linux/Windows GUI programming: GUI-fy a CLI using pyInstaller

[Bob Martin]

in 788357 20180105 132921 Kevin Walzer  wrote:
>On 1/1/18 11:45 AM, X. wrote:
>> Ulli Horlacher:
>>> I have to transfer a python 2.7 CLI programm into one with a (simple) GUI.
>>> The program must run on Linux and Windows and must be compilable with
>>> pyinstall, because I have to ship a standalone windows.exe
>>> Any kind of installer is not acceptable.
>>>
>>> Reading https://github.com/pyinstaller/pyinstaller/wiki/Supported-Packages
>>> supported GUI packages are PyGTK, PyQt4, PyQt5, wxPython
>>> I have tested tkinter by myself and it works, too.
>>> I do not like GTK and Qt, because they are too complex.
>>>
>>> I want to do VERY simple things and I prefer a simple GUI toolkit :-)
>>
>>
>> me too !
>>
>
>Try easygui:
>
>https://pypi.python.org/pypi/easygui

Looks like Zenity.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: has sourceforge exposed the dirty little secret ?

[Abdur-Rahmaan Janhangeer]

github?

On Fri, Jan 5, 2018 at 8:27 PM, Kim of K.  wrote:

>
> "Background
>
> We feel that the world still produces way too much software that is
> frankly substandard. The reasons for this are pretty simple: software
> producers do not pay enough attention [...]"
>
>
> quote from http://texttest.sourceforge.net/index.php?page=about
>
>
> In other words: most sites like SF and github offer tons of crap.
> download and break is the overwhelming theme here.
>
> why is no one complaining ?
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 7z archive reader akin to zipfile?

[Peter J. Holzer]

On 2018-01-03 12:10:22 -0600, Skip Montanaro wrote:
> The zipfile module is kind of cool because you can access elements of
> the archive without explicitly uncompressing the entire archive and
> writing the structure to disk. I've got some 7z archives I'd like to
> treat the same way (read specific elements without first extractingg
> the entire tree to disk). I see the pylzma module for compressing and
> uncompressing files, but nothing slightly higher level. Does something
> like that exist?

Have you looked at libarchive (https://pypi.python.org/pypi/libarchive)?
I think it does what you want and it transparently supports several
archive types (including zip and 7z).

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Spectre/Meltdown bug affecting Python ?

[Etienne Robillard]

Hi all,

What do you think about the latest Spectre/Meltdown security flaw found 
in Intel processors and Apple smartphones?


Are Python 2.7 and 3.6 affected by speculative execution side-channel 
attacks when using the Linux kernel and Intel CPUs?



Best regards,

Etienne

--
Etienne Robillard
tkad...@yandex.com
https://www.isotopesoftware.ca/

--
https://mail.python.org/mailman/listinfo/python-list

Re: Spectre/Meltdown bug affecting Python ?

[Etienne Robillard]

My understanding of this vulnerability is that speculative indirect 
calls in Linux kernel can be used to extract/filter memory content via 
side-channels.


So, is it time to implement --enable-retpoline to CPython ? [1]

Etienne

1. 
https://www.bleepingcomputer.com/news/google/google-unveils-new-retpoline-coding-technique-for-mitigating-spectre-attacks/



Le 2018-01-06 à 05:42, Etienne Robillard a écrit :

Hi all,

What do you think about the latest Spectre/Meltdown security flaw 
found in Intel processors and Apple smartphones?


Are Python 2.7 and 3.6 affected by speculative execution side-channel 
attacks when using the Linux kernel and Intel CPUs?



Best regards,

Etienne



--
Etienne Robillard
tkad...@yandex.com
https://www.isotopesoftware.ca/

--
https://mail.python.org/mailman/listinfo/python-list

Re: 7z archive reader akin to zipfile?

[Skip Montanaro]

> Have you looked at libarchive (https://pypi.python.org/pypi/libarchive)?

Thanks, was completely unaware of its existence. I will take a look.
I've been repackaging the 7z archives as zips, but the result is 3-5x
larger.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 7z archive reader akin to zipfile?

[Wanderer]

On Wednesday, January 3, 2018 at 1:11:31 PM UTC-5, Skip Montanaro wrote:
> The zipfile module is kind of cool because you can access elements of
> the archive without explicitly uncompressing the entire archive and
> writing the structure to disk. I've got some 7z archives I'd like to
> treat the same way (read specific elements without first extractingg
> the entire tree to disk). I see the pylzma module for compressing and
> uncompressing files, but nothing slightly higher level. Does something
> like that exist?
> 
> Thx,
> 
> Skip

I made this wrapper class for 7zip. It might be useful for you.

#python wrapper for 7zip
import os
import zlib
from subprocess import Popen, PIPE
"""
p = Popen(['program', 'arg1'], stdin=PIPE, stdout=PIPE, stderr=PIPE)
output, err = p.communicate(b"input data that is passed to subprocess' stdin")
rc = p.returncode
"""

SEVEN_ZIP_PATH = "C:/Program Files/7-Zip/7z.exe" 

class SevenZip(object):

def __new__(cls, ZipProgram=SEVEN_ZIP_PATH):
if os.path.isfile(ZipProgram):
return super(SevenZip, cls).__new__(cls)
else:
raise ValueError("7zip program not found in %s" %(ZipProgram))

def __init__(self, ZipProgram=SEVEN_ZIP_PATH):
self.ZipProgram = ZipProgram
self.archive = None
self.outputDir = None
self.fileList = []
self.archiveType = "zip"


def call(self, cmdList=None):
""" Used by the other methods to call the 7zip command line. 
Can be used directly to run 7zip if the wrapper methods don't suffice.

cmdList -- Subprocess style list of command line options with
the first item in the list being self.ZipProgram
"""
if cmdList is not None:
zip7 = Popen(cmdList, stdin=PIPE, stdout=PIPE, stderr=PIPE )
output ,err = zip7.communicate()
rc = zip7.returncode
print "output" , output
print "return code", rc
if len(err) > 0:
print "errors found", err

   
def modify(self, archive=None, fileList=None, cmd=None):
""" Modify an archive (add, delete or update)
[optional]
archive -- the zip file
fileList -- a list of file paths or a single filepath
cmd -- 'a': add, 'd': delete or 'u': update
"""
if not cmd in ['a','u','d']:
raise ValueError("Invalid command %s" %cmd)
if fileList is not None:
if type(fileList) is list:
self.fileList = fileList
else:
self.fileList = [fileList]
"""
for f in self.fileList:
if not (os.path.isfile(f) or os.path.isdir(f)):
raise ValueError("File %s not found" %f)
"""

if archive is not None:
self.archive = archive
if self.archive is not None:
if os.path.isfile(self.archive) or cmd == 'a':
cmdList = [self.ZipProgram, cmd, '-y'] 
if self.archiveType is not None:
cmdList.append("-t"+self.archiveType)
cmdList.append(self.archive)
cmdList.extend(self.fileList)
print cmdList
self.call(cmdList)
else:
raise ValueError("Archive not found in %s" %(self.archive)) 



def usage(self):
""" Returns the 7zip command line usage text. 
These options can be accessed directly with call.

7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18

Usage: 7z  [...]  [...]
   [<@listfiles...>]


  a: Add files to archive
  b: Benchmark
  d: Delete files from archive
  e: Extract files from archive (without using directory names)
  l: List contents of archive
  t: Test integrity of archive
  u: Update files to archive
  x: eXtract files with full paths

  -ai[r[-|0]]{@listfile|!wildcard}: Include archives
  -ax[r[-|0]]{@listfile|!wildcard}: eXclude archives
  -bd: Disable percentage indicator
  -i[r[-|0]]{@listfile|!wildcard}: Include filenames
  -m{Parameters}: set compression Method
  -o{Directory}: set Output directory
  -p{Password}: set Password
  -r[-|0]: Recurse subdirectories
  -scs{UTF-8 | WIN | DOS}: set charset for list files
  -sfx[{name}]: Create SFX archive
  -si[{name}]: read data from stdin
  -slt: show technical information for l (List) command
  -so: write data to stdout
  -ssc[-]: set sensitive case mode
  -ssw: compress shared files
  -t{Type}: Set type of archive
  -u[-][p#][

Re: [python-cffi] Fwd: Re: Progress migrating cffi and pycparser to libclang

[Eli Bendersky]

On Fri, Jan 5, 2018 at 1:15 AM, Etienne Robillard 
wrote:

> Forwarding  this thread to the CFFI developers...
>
> Re Paul: Thanks for your feedback.
>
> My intended audience are developers who can use hg to fetch/build source
> code without pip.
>
> Best regards,
>
> Etienne
>

I'd like to understand the requirements here better, from the point of view
of pycparser. What are you trying to accomplish?

One of the issues with parsing "original" headers (with #defines and
#includes and all that jazz) is that you have to match the compilation
environment very precisely. When a compiler compiles a large project it
could set dozens of -Ds, as well as -Is pointing to directories with
additional headers. This is usually specified in Makefiles or something
similar. Clang and libclang deal with this by having the concept of a
compilation database which remembers for each file what the exact flags to
compile it are (https://clang.llvm.org/docs/JSONCompilationDatabase.html)

To make this *really* work for CFFI you'd have to take all of this into
account -- do you really want to deal with this on the CFFI level?

Eli








>
>  Message transféré 
> Sujet : Re: Progress migrating cffi and pycparser to libclang
> Date : Thu, 4 Jan 2018 21:25:27 +
> De : Paul Moore  
> Pour : Etienne Robillard  
> Copie à : Python  
>
> On 4 January 2018 at 21:02, Etienne Robillard  
>  wrote:
> >> As a fork/extension for cffi, I have no particular opinion (I'm
> >> unlikely to ever use it). But the advantage of pycparser is that it's
> >> cross-platform and pure Python, so I doubt this will be acceptable for
> >> inclusion into CFFI itself.
> >
> > CFFI/pycparser definitely need to be patched to support parsing standard C
> > directives like #define and #include in the ffi.cdef() function.
> >
> > The easiest solution is to migrate the internal parsing code to libclang, a
> > state-of-the art C/C++ compiler based on LLVM.
>
> I would strongly object to adding a dependency to cffi that couldn't
> be automatically installed by pip as part of standard dependency
> resolution (i.e., a PyPI hosted Python project with wheels available
> for all common platforms - Linux, Mac OS and Windows). But ultimately
> if you're proposing this as a change to cffi, you should be getting
> the opinions of the cffi devs, not just asking on this list. (I notice
> you have posted to the cffi mailing list, but haven't had any response
> yet).
>
> Paul
>
>
> --
> -- python-cffi: To unsubscribe from this group, send email to
> python-cffi+unsubscr...@googlegroups.com. For more options, visit this
> group at https://groups.google.com/d/forum/python-cffi?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "python-cffi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to python-cffi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Spectre/Meltdown bug affecting Python ?

[J.O. Aho]

On 01/06/18 13:43, Etienne Robillard wrote:
> My understanding of this vulnerability is that speculative indirect
> calls in Linux kernel can be used to extract/filter memory content via
> side-channels.

Not just Linux, but all other OS:es, Microsoft and Apple been patching
in secret as they have a closed source approach, but ms-windows needs at
least one more patch before it can breath out, which will be released on
Tuesday.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Spectre/Meltdown bug affecting Python ?

[Etienne Robillard]

Le 2018-01-06 à 15:49, J.O. Aho a écrit :

On 01/06/18 13:43, Etienne Robillard wrote:

My understanding of this vulnerability is that speculative indirect
calls in Linux kernel can be used to extract/filter memory content via
side-channels.

Not just Linux, but all other OS:es, Microsoft and Apple been patching
in secret as they have a closed source approach, but ms-windows needs at
least one more patch before it can breath out, which will be released on
Tuesday.


It's unclear to me whether AMD CPUs are affected by theses design flaws.

Furthermore, I'd like to know if Python can mitigate hardware-specific 
timing attacks.


Best regards,

Etienne

--
Etienne Robillard
tkad...@yandex.com
https://www.isotopesoftware.ca/

--
https://mail.python.org/mailman/listinfo/python-list

Re: Spectre/Meltdown bug affecting Python ?

[Thomas Nyberg]

On 01/06/2018 10:23 PM, Etienne Robillard wrote:
> It's unclear to me whether AMD CPUs are affected by theses design flaws.

As far as I understand, AMD (and possibly ARM) is unaffected by Meltdown
(except for possibly some very new processors). It seems like basically
all modern out of order processors are affected by spectre. Obviously
there are many details/caveats. Here is a starting point:

Quoted from: https://spectreattack.com/
-
Which systems are affected by Meltdown?
Desktop, Laptop, and Cloud computers may be affected by Meltdown. More
technically, every Intel processor which implements out-of-order
execution is potentially affected, which is effectively every processor
since 1995 (except Intel Itanium and Intel Atom before 2013). We
successfully tested Meltdown on Intel processor generations released as
early as 2011. Currently, we have only verified Meltdown on Intel
processors. At the moment, it is unclear whether ARM and AMD processors
are also affected by Meltdown.

Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud
Servers, as well as Smartphones. More specifically, all modern
processors capable of keeping many instructions in flight are
potentially vulnerable. In particular, we have verified Spectre on
Intel, AMD, and ARM processors.
-

Cheers,
Thomas
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Spectre/Meltdown bug affecting Python ?

[Grant Edwards]

On 2018-01-06, Etienne Robillard  wrote:
>
>
> Le 2018-01-06 à 15:49, J.O. Aho a écrit :
>> On 01/06/18 13:43, Etienne Robillard wrote:
>>> My understanding of this vulnerability is that speculative indirect
>>> calls in Linux kernel can be used to extract/filter memory content via
>>> side-channels.
>> Not just Linux, but all other OS:es, Microsoft and Apple been patching
>> in secret as they have a closed source approach, but ms-windows needs at
>> least one more patch before it can breath out, which will be released on
>> Tuesday.
>
> It's unclear to me whether AMD CPUs are affected by theses design flaws.

Everybody seems to agree that AMD CPUs are not affected by Meltdown.
The consensus is that AMD CPUs are probably affected by 2 of the 3
Spectre variants.

> Furthermore, I'd like to know if Python can mitigate hardware-specific 
> timing attacks.

For CPython, probably not.  Anything that Cpython tried to do could be
trivially defeated by using something like ctypes to make calls to
arbitrary machine code that was written to a file.

-- 
Grant Edwards   grant.b.edwardsYow! Do I have a lifestyle
  at   yet?
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Spectre/Meltdown bug affecting Python ?

[Ian Kelly]

On Sat, Jan 6, 2018, 4:45 PM Grant Edwards 
wrote:

> On 2018-01-06, Etienne Robillard  wrote:
> >
> >
> > Le 2018-01-06 à 15:49, J.O. Aho a écrit :
> >> On 01/06/18 13:43, Etienne Robillard wrote:
> >>> My understanding of this vulnerability is that speculative indirect
> >>> calls in Linux kernel can be used to extract/filter memory content via
> >>> side-channels.
> >> Not just Linux, but all other OS:es, Microsoft and Apple been patching
> >> in secret as they have a closed source approach, but ms-windows needs at
> >> least one more patch before it can breath out, which will be released on
> >> Tuesday.
> >
> > It's unclear to me whether AMD CPUs are affected by theses design flaws.
>
> Everybody seems to agree that AMD CPUs are not affected by Meltdown.
> The consensus is that AMD CPUs are probably affected by 2 of the 3
> Spectre variants.
>
> > Furthermore, I'd like to know if Python can mitigate hardware-specific
> > timing attacks.
>
> For CPython, probably not.  Anything that Cpython tried to do could be
> trivially defeated by using something like ctypes to make calls to
> arbitrary machine code that was written to a file.
>

It sounds like you're talking about the case where the malicious code is
hosted by Python. I agree that's probably not realistic to do anything
about -- if you can run malicious code then you're probably not restricted
to Python (and without knowing a lot about the attacks, I'm doubtful that
it's possible to implement them in pure Python anyway).

I think the OP was talking about protecting the data of Python programs
from other malicious processes, however. The mitigation seems to be like it
could reasonably be accomplished (at least for core Python -- extension
code would be on its own).

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Spectre/Meltdown bug affecting Python ?

[Grant Edwards]

On 2018-01-06, Ian Kelly  wrote:
>
>> > Furthermore, I'd like to know if Python can mitigate hardware-specific
>> > timing attacks.
>>
>> For CPython, probably not.  Anything that Cpython tried to do could be
>> trivially defeated by using something like ctypes to make calls to
>> arbitrary machine code that was written to a file.
>>
>
> It sounds like you're talking about the case where the malicious code is
> hosted by Python. I agree that's probably not realistic to do anything
> about -- if you can run malicious code then you're probably not restricted
> to Python (and without knowing a lot about the attacks, I'm doubtful that
> it's possible to implement them in pure Python anyway).

Yes, that's what I was talking about.

> I think the OP was talking about protecting the data of Python programs
> from other malicious processes, however. The mitigation seems to be like it
> could reasonably be accomplished (at least for core Python -- extension
> code would be on its own).

Ah, yes.  Eventually it seems that just compiling CPython with a
compiler that uses something like Google's "retpoline" should help:

  https://support.google.com/faqs/answer/7625886

Though I think I understand what the retpoline _is_, I don't really
understand enough about the Spectre vulnerability say much else.

-- 
Grant Edwards   grant.b.edwardsYow! I'm having an
  at   emotional outburst!!
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list