DOCSLIB.ORG

Release 0.18.0-Pre

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Release 0.18.0-Pre PyOxidizer Release 0.18.0-pre Sep 27, 2021 Contents 1 Overview 3 1.1 Benefits of PyOxidizer..........................................3 1.2 Components...............................................4 1.3 How It Works...............................................4 2 Getting Started 7 2.1 Python Requirements...........................................7 2.2 Operating System Requirements.....................................7 2.3 Installing.................................................8 2.4 High-Level Project Lifecycle...................................... 10 2.5 Your First PyOxidizer Project...................................... 10 2.6 The pyoxidizer.bzl Configuration File.............................. 11 2.7 Customizing Python and Packaging Behavior.............................. 11 3 The pyoxidizer Command Line Tool 13 3.1 Settings.................................................. 13 3.2 Creating New Projects with init-config-file .......................... 14 3.3 Creating New Rust Projects with init-rust-project ....................... 14 3.4 Building PyObject Projects with build ................................ 14 3.5 Running the Result of Building with run ................................ 15 3.6 Analyzing Produced Binaries with analyze .............................. 15 3.7 Inspecting Python Distributions..................................... 15 3.8 Debugging Resource Scanning and Identification with find-resources .............. 16 3.9 Defining Extra Variables in Starlark Environment............................ 17 4 Configuration Files 19 4.1 Automatic File Location Strategy.................................... 19 4.2 Concepts................................................. 19 4.3 Resource Attributes Influencing Adding................................. 21 4.4 Global Symbols............................................. 22 4.5 Functions for Manipulating Global State................................ 24 4.6 Functions for Managing Targets..................................... 25 4.7 Extensions to Tugger’s Starlark Dialect................................. 25 4.8 File ................................................... 26 4.9 PythonDistribution ........................................ 27 4.10 PythonEmbeddedResources .................................... 29 4.11 PythonExecutable ......................................... 29 i 4.12 PythonExtensionModule ..................................... 34 4.13 PythonInterpreterConfig .................................... 35 4.14 PythonModuleSource ........................................ 47 4.15 PythonPackageResource ..................................... 48 4.16 PythonPackageDistributionResource ............................ 48 4.17 PythonPackagingPolicy ..................................... 49 5 Packaging User Guide 53 5.1 Creating a PyOxidizer Project...................................... 53 5.2 Packaging Primitives in pyoxidizer.bzl Files........................... 54 5.3 Understanding Python Distributions................................... 56 5.4 Managing How Resources are Added.................................. 58 5.5 Packaging Python Files......................................... 64 5.6 Packaging Files Instead of In-Memory Resources............................ 69 5.7 Working with Python Extension Modules................................ 74 5.8 Managing Packed Resources Data.................................... 76 5.9 Trimming Unused Resources...................................... 78 5.10 Performance of Built Binaries...................................... 78 5.11 Packaging Pitfalls............................................ 80 5.12 Masquerading As Other Packaging Tools................................ 81 5.13 Standalone / Single File Applications with Static Linking....................... 82 5.14 Licensing Considerations........................................ 84 5.15 Terminfo Database............................................ 85 5.16 Using the multiprocessing Python Module............................ 86 5.17 SSL Certificate Loading......................................... 88 5.18 Using the tkinter Python Module.................................. 90 5.19 Building an Executable that Behaves Like python ........................... 91 6 Distributing User Guide 95 6.1 Overview................................................. 95 6.2 Portability of Binaries Built with PyOxidizer.............................. 96 6.3 Building Windows Installers with the WiX Toolset........................... 96 6.4 Distribution Considerations for Linux.................................. 97 6.5 Distribution Considerations for macOS................................. 99 6.6 Distribution Considerations for Windows................................ 101 7 oxidized_importer Python Extension 105 7.1 Getting Started.............................................. 105 7.2 Python Meta Path Finders........................................ 106 7.3 OxidizedFinder Meta Path Finder................................. 107 7.4 OxidizedFinder Behavior and Compliance............................. 108 7.5 oxidized_importer Python Resource Types............................ 112 7.6 Resource Scanning APIs......................................... 114 7.7 Loading Resource Files......................................... 114 7.8 Freezing Applications with oxidized_importer .......................... 120 7.9 OxidizedZipFinder Meta Path Finder............................... 122 7.10 Common Issues............................................. 123 7.11 Security Implications of Loading Resources............................... 124 7.12 API Reference.............................................. 124 7.13 Python Packed Resources........................................ 133 8 The pyembed Rust Crate 141 8.1 Controlling Python from Rust Code................................... 141 8.2 Adding Extension Modules At Run-Time................................ 142 ii 9 PyOxidizer for Rust Developers 143 9.1 Using Cargo with PyOxidizer Source Checkouts............................ 143 9.2 PyOxidizer Rust Projects......................................... 144 9.3 Controlling Python From Rust Code................................... 147 9.4 Porting a Python Application to Rust.................................. 149 10 Shipping Applications with tugger 155 10.1 Overview................................................. 155 10.2 Tugger Starlark Dialect.......................................... 156 10.3 Working with Files............................................ 178 10.4 Code Signing............................................... 179 10.5 Using the WiX Toolset to Produce Windows Installers......................... 187 10.6 Project History.............................................. 189 11 The PyOxy Python Runner 191 11.1 Overview................................................. 191 11.2 Running YAML Based Applications................................... 192 11.3 Development Guide........................................... 193 12 Frequently Asked Questions 195 12.1 Where Can I Report Bugs / Send Feedback / Request Features?.................... 195 12.2 Why Build Another Python Application Packaging Tool?........................ 195 12.3 Can Python 2.7 Be Supported?...................................... 196 12.4 Why is Python 3.8 Required?...................................... 196 12.5 No python interpreter found of version 3.* Error When Building......... 196 12.6 Why Rust?................................................ 196 12.7 Why is the Rust Code. Not Great?.................................. 197 12.8 What is the Magic Sauce That Makes PyOxidizer Special?....................... 197 12.9 Can Applications Import Python Modules from the Filesystem?.................... 197 12.10 error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory When Building......... 198 12.11 vcruntime140.dll was not found Error on Windows.................... 198 12.12 ld: unsupported tapi file type '!tapi-tbd' in YAML file on macOS When Building.............................................. 198 13 Project Status 199 13.1 What’s Working............................................. 199 13.2 Major Missing Features......................................... 199 13.3 Lesser Missing Features......................................... 201 13.4 Eventual Features............................................ 201 14 Comparisons to Other Tools 205 14.1 PyInstaller................................................ 205 14.2 py2exe.................................................. 206 14.3 py2app.................................................. 206 14.4 cx_Freeze................................................. 206 14.5 Shiv.................................................... 206 14.6 PEX.................................................... 207 14.7 XAR................................................... 207 14.8 Docker / Running a Container...................................... 207 14.9 Nuitka.................................................. 207 14.10 PyRun.................................................. 207 14.11 pynsist.................................................. 208 14.12 Bazel................................................... 208 iii 15 Contributing to PyOxidizer 209 15.1 As a User................................................. 209 15.2 As a Developer.............................................. 209 15.3 Financial Contributions......................................... 210 16 Project History 211 16.1 Blog Posts................................................ 211 16.2 Version
Load more

Recommended publications
  • Tesi Final Marco Oliverio.Pdf
    i Abstract Advancements in exploitation techniques call for the need of advanced defenses. Modern operating systems have to face new sophisticate attacks that do not rely on any programming mistake, rather they exploit leaking information from computational side effects (side-channel attacks) or hardware glitches (rowhammer attacks). Mitigating these new attacks poses new challanges and involves delicate trade-offs, balancing security on one side and performance, simplicity, and compatibility on the other. In this disseration we explore the attack surface exposed by page fusion, a memory saving optimization in modern operating systems and, after that, a secure page fusion implementation called VUsion is shown. We then propose a complete and compatible software solution to rowhammer attacks called ZebRAM. Lastly, we show OpenCAL, a free and general libray for the implementation of Cellular Automata, that can be used in several security scenarios. iii Acknowledgements I would like to thank my Supervisor prof. Andrea Pugliese for the encouragement and the extremely valuable advice that put me in a fruitful and exciting research direction. A hearty acknowledgment goes to Kaveh Razavi, Cristiano Giuffrida, Herbert Bos and all the VUSec group of the Vrije Universiteit of Amsterdam. I felt at home from day one and I found myself surrounded by brilliant researchers and good friends. v Contents Abstract i Acknowledgements iii Introduction1 1 VUsion3 1.1 Introduction...................................3 1.2 Page Fusion...................................5 1.2.1 Linux Kernel Same-page Merging...................5 1.2.2 Windows Page Fusion.........................7 1.3 Threat Model..................................8 1.4 Known Attack Vectors.............................8 1.4.1 Information Disclosure.........................8 1.4.2 Flip Feng Shui.............................9 1.5 New Attack Vectors..............................
    [Show full text]
  • An In-Depth Study with All Rust Cves
    Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs HUI XU, School of Computer Science, Fudan University ZHUANGBIN CHEN, Dept. of CSE, The Chinese University of Hong Kong MINGSHEN SUN, Baidu Security YANGFAN ZHOU, School of Computer Science, Fudan University MICHAEL R. LYU, Dept. of CSE, The Chinese University of Hong Kong Rust is an emerging programing language that aims at preventing memory-safety bugs without sacrificing much efficiency. The claimed property is very attractive to developers, and many projects start usingthe language. However, can Rust achieve the memory-safety promise? This paper studies the question by surveying 186 real-world bug reports collected from several origins which contain all existing Rust CVEs (common vulnerability and exposures) of memory-safety issues by 2020-12-31. We manually analyze each bug and extract their culprit patterns. Our analysis result shows that Rust can keep its promise that all memory-safety bugs require unsafe code, and many memory-safety bugs in our dataset are mild soundness issues that only leave a possibility to write memory-safety bugs without unsafe code. Furthermore, we summarize three typical categories of memory-safety bugs, including automatic memory reclaim, unsound function, and unsound generic or trait. While automatic memory claim bugs are related to the side effect of Rust newly-adopted ownership-based resource management scheme, unsound function reveals the essential challenge of Rust development for avoiding unsound code, and unsound generic or trait intensifies the risk of introducing unsoundness. Based on these findings, we propose two promising directions towards improving the security of Rust development, including several best practices of using specific APIs and methods to detect particular bugs involving unsafe code.
    [Show full text]
  • Ensuring the Spatial and Temporal Memory Safety of C at Runtime
    MemSafe: Ensuring the Spatial and Temporal Memory Safety of C at Runtime Matthew S. Simpson, Rajeev K. Barua Department of Electrical & Computer Engineering University of Maryland, College Park College Park, MD 20742-3256, USA fsimpsom, [email protected] Abstract—Memory access violations are a leading source of dereferencing pointers obtained from invalid pointer arith- unreliability in C programs. As evidence of this problem, a vari- metic; and dereferencing uninitialized, NULL or “manufac- ety of methods exist that retrofit C with software checks to detect tured” pointers.1 A temporal error is a violation caused by memory errors at runtime. However, these methods generally suffer from one or more drawbacks including the inability to using a pointer whose referent has been deallocated (e.g. with detect all errors, the use of incompatible metadata, the need for free) and is no longer a valid object. The most well-known manual code modifications, and high runtime overheads. temporal violations include dereferencing “dangling” point- In this paper, we present a compiler analysis and transforma- ers to dynamically allocated memory and freeing a pointer tion for ensuring the memory safety of C called MemSafe. Mem- more than once. Dereferencing pointers to automatically allo- Safe makes several novel contributions that improve upon previ- ous work and lower the cost of safety. These include (1) a method cated memory (stack variables) is also a concern if the address for modeling temporal errors as spatial errors, (2) a compati- of the referent “escapes” and is made available outside the ble metadata representation combining features of object- and function in which it was defined.
    [Show full text]
  • Improving Memory Management Security for C and C++
    Improving memory management security for C and C++ Yves Younan, Wouter Joosen, Frank Piessens, Hans Van den Eynden DistriNet, Katholieke Universiteit Leuven, Belgium Abstract Memory managers are an important part of any modern language: they are used to dynamically allocate memory for use in the program. Many managers exist and depending on the operating system and language. However, two major types of managers can be identified: manual memory allocators and garbage collectors. In the case of manual memory allocators, the programmer must manually release memory back to the system when it is no longer needed. Problems can occur when a programmer forgets to release it (memory leaks), releases it twice or keeps using freed memory. These problems are solved in garbage collectors. However, both manual memory allocators and garbage collectors store management information for the memory they manage. Often, this management information is stored where a buffer overflow could allow an attacker to overwrite this information, providing a reliable way to achieve code execution when exploiting these vulnerabilities. In this paper we describe several vulnerabilities for C and C++ and how these could be exploited by modifying the management information of a representative manual memory allocator and a garbage collector. Afterwards, we present an approach that, when applied to memory managers, will protect against these attack vectors. We implemented our approach by modifying an existing widely used memory allocator. Benchmarks show that this implementation has a negligible, sometimes even beneficial, impact on performance. 1 Introduction Security has become an important concern for all computer users. Worms and hackers are a part of every day internet life.
    [Show full text]
  • Free Tools Photosynth
    Free Tools Photosynth Making a Photosynth Creating the best synth starts with the right photos. Here are some key tips: • Take overlapping panoramas from different locations • Have lots of overlap between shots to get good matching • Limit the angles between photos (no more than 25 degrees – at least 15 per full rotation) • Pick scenes or objects with lots of detail and texture • Don’t crop your images before synthing • Rotate your photos to be ‘up’ correctly before synthing Once you have signed in, click the Upload button (top right of page) or click on the Create your Synth icon on the home page. (scroll down). If you do not have the software you will be prompted to download it first. Once it is installed you will see the Create a Synth button. You will see a pop-up window with Start a new synth button. Give your synth a name, tags (descriptive words) and description. Click Add Photos, browse to your files add them. Then click on the Synth button at the bottom of the page. Photosynth will do the rest for you. Making a Panorama Many photosynths consist of photos shot from a single location. Our friends in Microsoft Research have developed a free, world class panoramic image stitcher called Microsoft Image Composite Editor (ICE for short.) ICE takes a set of overlapping photographs of a scene shot from a single camera location, and creates a single high-resolution image. Photosynth now has support for uploading, exploring and viewing ICE panoramas alongside normal synths. Here’s how to create a panorama in ICE and upload it to Photosynth: 1.
    [Show full text]
  • Buffer Overflows Buffer Overflows
    L15: Buffer Overflow CSE351, Spring 2017 Buffer Overflows CSE 351 Spring 2017 Instructor: Ruth Anderson Teaching Assistants: Dylan Johnson Kevin Bi Linxing Preston Jiang Cody Ohlsen Yufang Sun Joshua Curtis L15: Buffer Overflow CSE351, Spring 2017 Administrivia Homework 3, due next Friday May 5 Lab 3 coming soon 2 L15: Buffer Overflow CSE351, Spring 2017 Buffer overflows Address space layout (more details!) Input buffers on the stack Overflowing buffers and injecting code Defenses against buffer overflows 3 L15: Buffer Overflow CSE351, Spring 2017 not drawn to scale Review: General Memory Layout 2N‐1 Stack Stack . Local variables (procedure context) Heap . Dynamically allocated as needed . malloc(), calloc(), new, … Heap Statically allocated Data . Read/write: global variables (Static Data) Static Data . Read‐only: string literals (Literals) Code/Instructions Literals . Executable machine instructions Instructions . Read‐only 0 4 L15: Buffer Overflow CSE351, Spring 2017 not drawn to scale x86‐64 Linux Memory Layout 0x00007FFFFFFFFFFF Stack Stack . Runtime stack has 8 MiB limit Heap Heap . Dynamically allocated as needed . malloc(), calloc(), new, … Statically allocated data (Data) Shared Libraries . Read‐only: string literals . Read/write: global arrays and variables Code / Shared Libraries Heap . Executable machine instructions Data . Read‐only Instructions Hex Address 0x400000 0x000000 5 L15: Buffer Overflow CSE351, Spring 2017 not drawn to scale Memory Allocation Example Stack char big_array[1L<<24]; /* 16 MB */ char huge_array[1L<<31]; /* 2 GB */ int global = 0; Heap int useless() { return 0; } int main() { void *p1, *p2, *p3, *p4; Shared int local = 0; Libraries p1 = malloc(1L << 28); /* 256 MB */ p2 = malloc(1L << 8); /* 256 B */ p3 = malloc(1L << 32); /* 4 GB */ p4 = malloc(1L << 8); /* 256 B */ Heap /* Some print statements ..
    [Show full text]
  • Mobilizing (Ourselves) for a Critical Digital Archaeology Adam Rabinowitz University of Texas at Austin, [email protected]
    University of Wisconsin Milwaukee UWM Digital Commons Mobilizing the Past Art History 10-21-2016 5.2. Response: Mobilizing (Ourselves) for a Critical Digital Archaeology Adam Rabinowitz University of Texas at Austin, [email protected] Follow this and additional works at: https://dc.uwm.edu/arthist_mobilizingthepast Part of the Classical Archaeology and Art History Commons Recommended Citation Rabinowitz, Adam. “Response: Mobilizing (Ourselves) for a Critical Digital Archaeology.” In Mobilizing the Past for a Digital Future: The Potential of Digital Archaeology, edited by Erin Walcek Averett, Jody Michael Gordon, and Derek B. Counts, 493-518. Grand Forks, ND: The Digital Press at the University of North Dakota, 2016. This Book is brought to you for free and open access by UWM Digital Commons. It has been accepted for inclusion in Mobilizing the Past by an authorized administrator of UWM Digital Commons. For more information, please contact [email protected]. MOBILIZING THE PAST FOR A DIGITAL FUTURE MOBILIZING the PAST for a DIGITAL FUTURE The Potential of Digital Archaeology Edited by Erin Walcek Averett Jody Michael Gordon Derek B. Counts The Digital Press @ The University of North Dakota Grand Forks Creative Commons License This work is licensed under a Creative Commons By Attribution 4.0 International License. 2016 The Digital Press @ The University of North Dakota Book Design: Daniel Coslett and William Caraher Cover Design: Daniel Coslett Library of Congress Control Number: 2016917316 The Digital Press at the University of North Dakota, Grand Forks, North Dakota ISBN-13: 978-062790137 ISBN-10: 062790137 Version 1.1 (updated November 5, 2016) Table of Contents Preface & Acknowledgments v How to Use This Book xi Abbreviations xiii Introduction Mobile Computing in Archaeology: Exploring and Interpreting Current Practices 1 Jody Michael Gordon, Erin Walcek Averett, and Derek B.
    [Show full text]
  • Memory Vulnerability Diagnosis for Binary Program
    ITM Web of Conferences 7 03004 , (2016) DOI: 10.1051/itmconf/20160703004 ITA 2016 Memory Vulnerability Diagnosis for Binary Program Feng-Yi TANG, Chao FENG and Chao-Jing TANG College of Electronic Science and Engineering National University of Defense Technology Changsha, China Abstract. Vulnerability diagnosis is important for program security analysis. It is a further step to understand the vulnerability after it is detected, as well as a preparatory step for vulnerability repair or exploitation. This paper mainly analyses the inner theories of major memory vulnerabilities and the threats of them. And then suggests some methods to diagnose several types of memory vulnerabilities for the binary programs, which is a difficult task due to the lack of source code. The diagnosis methods target at buffer overflow, use after free (UAF) and format string vulnerabilities. We carried out some tests on the Linux platform to validate the effectiveness of the diagnosis methods. It is proved that the methods can judge the type of the vulnerability given a binary program. 1 Introduction (or both) the memory area. These headers can contain some information like size, used or not, and etc. Memory vulnerabilities are difficult to detect and diagnose Therefore, we can monitor the allocator so as to especially for those do not crash the program. Due to its determine the base address and the size of the allocation importance, vulnerability diagnosis problem has been areas. Then, check all STORE and LOAD accesses in intensively studied. Researchers have proposed different memory to see which one is outside the allocated area. techniques to diagnose memory vulnerabilities.
    [Show full text]
  • A Buffer Overflow Study
    A Bu®er Overflow Study Attacks & Defenses Pierre-Alain FAYOLLE, Vincent GLAUME ENSEIRB Networks and Distributed Systems 2002 Contents I Introduction to Bu®er Overflows 5 1 Generalities 6 1.1 Process memory . 6 1.1.1 Global organization . 6 1.1.2 Function calls . 8 1.2 Bu®ers, and how vulnerable they may be . 10 2 Stack overflows 12 2.1 Principle . 12 2.2 Illustration . 12 2.2.1 Basic example . 13 2.2.2 Attack via environment variables . 14 2.2.3 Attack using gets . 16 3 Heap overflows 18 3.1 Terminology . 18 3.1.1 Unix . 18 3.1.2 Windows . 18 3.2 Motivations and Overview . 18 3.3 Overwriting pointers . 19 3.3.1 Di±culties . 20 3.3.2 Interest of the attack . 20 3.3.3 Practical study . 20 3.4 Overwriting function pointers . 24 3.4.1 Pointer to function: short reminder . 24 3.4.2 Principle . 24 3.4.3 Example . 25 3.5 Trespassing the heap with C + + . 28 3.5.1 C++ Background . 28 3.5.2 Overwriting the VPTR . 31 3.5.3 Conclusions . 32 3.6 Exploiting the malloc library . 33 3.6.1 DLMALLOC: structure . 33 3.6.2 Corruption of DLMALLOC: principle . 34 II Protection solutions 37 4 Introduction 38 1 5 How does Libsafe work? 39 5.1 Presentation . 39 5.2 Why are the functions of the libC unsafe ? . 39 5.3 What does libsafe provide ? . 40 6 The Grsecurity Kernel patch 41 6.1 Open Wall: non-executable stack .
    [Show full text]
  • Buffer Overflow and Format String Overflow Vulnerabilities 3
    Syracuse University SURFACE Electrical Engineering and Computer Science College of Engineering and Computer Science 2002 Buffer Overflow and ormatF String Overflow ulnerV abilities Kyung-suk Lhee Syracuse University Steve J. Chapin Syracuse University Follow this and additional works at: https://surface.syr.edu/eecs Part of the Computer Sciences Commons Recommended Citation Lhee, Kyung-suk and Chapin, Steve J., "Buffer Overflow and ormatF String Overflow ulnerV abilities" (2002). Electrical Engineering and Computer Science. 96. https://surface.syr.edu/eecs/96 This Article is brought to you for free and open access by the College of Engineering and Computer Science at SURFACE. It has been accepted for inclusion in Electrical Engineering and Computer Science by an authorized administrator of SURFACE. For more information, please contact [email protected]. SOFTWARE|PRACTICE AND EXPERIENCE Softw. Pract. Exper. 2002; 00:1{7 Bu®er Overflow and Format String Overflow Vulnerabilities Kyung-Suk Lhee and Steve J. Chapin¤,y Center for Systems Assurance, Syracuse University, Syracuse, NY 13210 SUMMARY Bu®er overflow vulnerabilities are among the most widespread of security problems. Numerous incidents of bu®er overflow attacks have been reported and many solutions have been proposed, but a solution that is both complete and highly practical is yet to be found. Another kind of vulnerability called format string overflow has recently been found, and though not as popular as bu®er overflow, format string overflow attacks are no less dangerous. This article surveys representative techniques of exploiting bu®er overflow and format string overflow vulnerabilities and their currently available defensive measures. We also describe our bu®er overflow detection technique that range checks the referenced bu®ers at run time.
    [Show full text]
  • Chapter 10 Buffer Overflow Buffer Overflow
    Chapter 10 Buffer Overflow Buffer Overflow ● Common attack mechanism ○ first wide use by the Morris Worm in 1988 ● Prevention techniques known ○ NX bit, stack canaries, ASLR ● Still of major concern ○ Recent examples: Shellshock, Hearthbleed Buffer Overflow/Buffer Overrun Definition: A condition at an interface under which more input can be placed into a buffer or data holding area than the capacity allocated, overwriting other information. Attackers exploit such a condition to crash a system or to insert specially crafted code that allows them to gain control of the system. Buffer Overflow Basics ● Programming error when a process attempts to store data beyond the limits of a fixed-sized buffer ● Overwrites adjacent memory locations ○ locations may hold other program variables, parameters, or program control flow data ○ buffer could be located on the stack, in the heap, or in the data section of the process ● Consequences: ○ corruption of program data ○ unexpected transfer of control ○ memory access violations Basic Buffer Overflow Example Basic Buffer Overflow Stack Values Buffer Overflow Attacks Attacker needs: ● To identify a buffer overflow vulnerability in some program that can be triggered using externally sourced data under the attacker’s control ● To understand how that buffer is stored in memory and determine potential for corruption Identifying vulnerable programs can be done by: ● inspection of program source ● tracing the execution of programs as they process oversized input ● using tools such as fuzzing to automatically identify
    [Show full text]
  • Los Gatos - Saratoga Camera Club Newsletter Vol
    Los Gatos - Saratoga Camera Club Newsletter Vol. 31 Issue 8 August 2009 2009 Calendar August 3 Competition: Color, PJ, and Travel - Slides and Digital Images. Color, PJ, and Monochrome - Prints. 17 NO MEETING (Board Meeting Only: 7PM) ©Julie Kitzenberger September 7 NO MEETING 21 Program: TBD and Post Card Judging JULIE KITZENBERGER PHOTOGRAPHY Fine Art Landscapes - Travel - Events [email protected] 408-348-4199 http://photo.net/photos/JulieKitzenberger ©Julie Kitzenberger A Solo Show: “Captured Landscapes and Abstracts – with a Touch of Us” July 28 – August 23, 2009 Reception/Meet the Photographer: Saturday, August 1, 2009, 5 – 8 pm AEGIS GALLERY OF FINE ART www.Aegisgallery.com/ Gallery hours: 14531 Big Basin Way at 4th Street Sun, Tue, Wed: 11 AM – 7 PM Saratoga , CA 95070 Thu, Fri, Sat: 11 AM – 9 PM (408) 867-0171 Closed Mondays LOS GATOS/SARATOGA CAMERA CLUB EXHIBIT 2009 Theme: Through the Lens: Photographic Moments Sign Ups Begin July 6 It’s time to begin planning for our Club’s seventh annual photography exhibit that is scheduled to run November 12 through January 7, 2010. This exclusive LG/SCC show provides Club members the opportunity to exhibit their work in the “Art in the Council Chambers program sponsored by the Los Gatos Arts Commission and held in the Los Gatos Council Chambers. SIGN-UPS: Beginning at the July 6 meeting, Club sign-ups will run until September 1. At that time the final number of images per person (up to 2 each) will be determined. All exhibit photos must be matted and framed under glass (or plexi) See Club website for complete exhibit timelines and hanging information.
    [Show full text]