junaidpv

#!/usr/bin/python
# -*- coding: utf-8 -*-

"""
A simple thread pool.

@author: Junaid P V
@license: GPLv3
"""
    

saetia

ruby -e "$(curl -fsSkL https://gist.githubusercontent.com/saetia/2369908/raw/4bf9a6d36060582e69f02c314f66449971a7bb11/parse.rb)" /Users/Joel/site.db.121010.dump

ruby parse.rb site.120411.dump

andreif

# coding=utf-8
"""
LICENSE http://www.apache.org/licenses/LICENSE-2.0
"""
import datetime
import sys
import time
import threading
import traceback
import SocketServer

fridolin-koch

<?php
//autoloader
require_once __DIR__ . '/vendor/autoload.php';

use Aws\S3\S3Client;
use Aws\S3\Enum\CannedAcl;
//init client
$s3Client = S3Client::factory(array(
    'key'       => '<key>',
    'secret'    => '<secret>',

hgfischer

Benchmarking Nginx with Go

There are a lot of ways to serve a Go HTTP application. The best choices depend on each use case. Currently nginx looks to be the standard web server for every new project even though there are other great web servers as well. However, how much is the overhead of serving a Go application behind an nginx server? Do we need some nginx features (vhosts, load balancing, cache, etc) or can you serve directly from Go? If you need nginx, what is the fastest connection mechanism? This are the kind of questions I'm intended to answer here. The purpose of this benchmark is not to tell that Go is faster or slower than nginx. That would be stupid.

So, these are the different settings we are going to compare:

• Go HTTP standalone (as the control group)
• Nginx proxy to Go HTTP
• Nginx fastcgi to Go TCP FastCGI
• Nginx fastcgi to Go Unix Socket FastCGI

ezimuel

<?php
// The libxml entity loader is disabled by default
// even setting the libxml_disable_entity_loader to false doesn't works!
//
// @see http://uk3.php.net/manual/en/function.libxml-disable-entity-loader.php
// @see http://stackoverflow.com/a/10213239

$dir = __DIR__;
$content = 'This is a remote content!';
file_put_contents('content.txt', $content);

sh1n0b1

#!/usr/bin/python

# Quick and dirty demonstration of CVE-2014-0160 by Jared Stafford (jspenguin@jspenguin.org)
# The author disclaims copyright to this source code.

import sys
import struct
import socket
import time
import select

MattWilcox

#!/usr/bin/env bash

# names of latest versions of each package
export VERSION_PCRE=pcre-8.38
export VERSION_OPENSSL=openssl-1.0.2d
export VERSION_NGINX=nginx-1.9.7

# URLs to the source directories
export SOURCE_OPENSSL=https://www.openssl.org/source/
export SOURCE_PCRE=ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/

rongarret

It appears that Safari does not enforce any kind of access
restrictions for XMLHTTPRequests on FILE: scheme URLs.  As a
result, any HTML file on the local file system that is opened in
Safari can read any file that the user has access to (and, of
course, it can upload those files too).  Here's a little
proof-of-concept.  Copy and paste this into a local HTML file and
open it in Safari.  It will display the contents of /etc/passwd.
 
<script src=https://code.jquery.com/jquery-2.1.3.min.js></script> 
<script>

epixoip

8x GTX 980 cudaHashcat Benchmark

Product: Sagitta Brutalis 980 (PN S2480-GTX-980)

Software: cudaHashcat 1.36b25, ForceWare 346.35

Accelerator: 8x Nvidia GTX 980 reference design, +250 clock offset

Highlights