Git-secret – store private data in a Git repo

{“protip”:{“public_id”:”e-azzg”,”title”:”Store your private data inside a git repository”,”body”:”There’s a known problem in server configuration and deploying, when you have to store your private data such as: database passwords, application secret-keys, OAuth secret keys and so on, outside of the git repository. Even if this repository is private, it is a security risk to just publish them into the world wide web. What are the drawbacks of storing them separately?rnrnThese files are not version controlled. Filenames change, locations change, passwords change from time to time, some new information appears, other is removed. And you can not tell for sure which version of the configuration file was used with each commit.rnWhen building the automated deployment system there will be one extra step: download and place these secret-configuration files where they need to be. So you have to maintain an extra secure server, where everything is stored.rnrn## How does git-secret solve these problems?rnrn`git-secret` encrypts files and stores them inside the git repository, so you will have all the changes for every commit.rn`git-secret` doesn’t require any other deploy operations rather than `git secret reveal`, so it will automatically decrypt all the required files.rnrn## What is git-secret?rnrn`git-secret` is a bash tool to store your private data inside a git repo. How’s that? Basically, it just encrypts, using `gpg`, the tracked files with the public keys of all the users that you trust. So everyone of them can decrypt these files using only their personal secret key. Why deal with all this private-public keys stuff? Well, to make it easier for everyone to manage access rights. There are no passwords that change. When someone is out – just delete his public key, reencrypt the files, and he won’t be able to decrypt secrets anymore.rnrn## UsagernThese steps cover the basic process of using `git-secret`:rnrn0. Before starting, make sure you have created `gpg` RSA key-pair: public and secret key identified by your email address.rn1. Initialize `git-secret` repository by running `git secret init` command. `.gitsecret/` folder will be created.rn2. Add first user to the system by running `git secret tell your@gpg.email-id`.rn3. Now it’s time to add files you wish to encrypt inside the `git-secret` repository. It can be done by running `git secret add ` command. Make sure these files are ignored, otherwise `git secret` won’t allow you to add them, as these files will be stored unencrypted.rn4. When done, run `git secret hide` all files, which you have added by `git secret add` command will be encrypted with added public-keys by the `git secret tell` command. Now it is safe to commit your changes. **But**. It’s recommended to add `git secret hide` command to your `pre-commit` hook, so you won’t miss any changes.rn5. Now decrypt files with `git secret reveal` command. It will ask you for your password. And you’re done!rnrnCheck out [docs](https://sobolevn.github.io/git-secret/#usage) for more information.”,”html”:”u003cpu003eThere’s a known problem in server configuration and deploying, when you have to store your private data such as: database passwords, application secret-keys, OAuth secret keys and so on, outside of the git repository. Even if this repository is private, it is a security risk to just publish them into the world wide web. What are the drawbacks of storing them separately?u003c/pu003ennu003cpu003eThese files are not version controlled. Filenames change, locations change, passwords change from time to time, some new information appears, other is removed. And you can not tell for sure which version of the configuration file was used with each commit.u003cbru003enWhen building the automated deployment system there will be one extra step: download and place these secret-configuration files where they need to be. So you have to maintain an extra secure server, where everything is stored.u003c/pu003ennu003ch2u003eHow does git-secret solve these problems?u003c/h2u003ennu003cpu003eu003ccode class=”prettyprint”u003egit-secretu003c/codeu003e encrypts files and stores them inside the git repository, so you will have all the changes for every commit.u003cbru003enu003ccode class=”prettyprint”u003egit-secretu003c/codeu003e doesn’t require any other deploy operations rather than u003ccode class=”prettyprint”u003egit secret revealu003c/codeu003e, so it will automatically decrypt all the required files.u003c/pu003ennu003ch2u003eWhat is git-secret?u003c/h2u003ennu003cpu003eu003ccode class=”prettyprint”u003egit-secretu003c/codeu003e is a bash tool to store your private data inside a git repo. How’s that? Basically, it just encrypts, using u003ccode class=”prettyprint”u003egpgu003c/codeu003e, the tracked files with the public keys of all the users that you trust. So everyone of them can decrypt these files using only their personal secret key. Why deal with all this private-public keys stuff? Well, to make it easier for everyone to manage access rights. There are no passwords that change. When someone is out – just delete his public key, reencrypt the files, and he won’t be able to decrypt secrets anymore.u003c/pu003ennu003ch2u003eUsageu003c/h2u003ennu003cpu003eThese steps cover the basic process of using u003ccode class=”prettyprint”u003egit-secretu003c/codeu003e:u003c/pu003ennu003colu003enu003cliu003eBefore starting, make sure you have created u003ccode class=”prettyprint”u003egpgu003c/codeu003e RSA key-pair: public and secret key identified by your email address.u003c/liu003enu003cliu003eInitialize u003ccode class=”prettyprint”u003egit-secretu003c/codeu003e repository by running u003ccode class=”prettyprint”u003egit secret initu003c/codeu003e command. u003ccode class=”prettyprint”u003e.gitsecret/u003c/codeu003e folder will be created.u003c/liu003enu003cliu003eAdd first user to the system by running u003ccode class=”prettyprint”u003egit secret tell your@gpg.email-idu003c/codeu003e.u003c/liu003enu003cliu003eNow itu0026#39;s time to add files you wish to encrypt inside the u003ccode class=”prettyprint”u003egit-secretu003c/codeu003e repository. It can be done by running u003ccode class=”prettyprint”u003egit secret add u0026lt;filenames…u0026gt;u003c/codeu003e command. Make sure these files are ignored, otherwise u003ccode class=”prettyprint”u003egit secretu003c/codeu003e wonu0026#39;t allow you to add them, as these files will be stored unencrypted.u003c/liu003enu003cliu003eWhen done, run u003ccode class=”prettyprint”u003egit secret hideu003c/codeu003e all files, which you have added by u003ccode class=”prettyprint”u003egit secret addu003c/codeu003e command will be encrypted with added public-keys by the u003ccode class=”prettyprint”u003egit secret tellu003c/codeu003e command. Now it is safe to commit your changes. u003cstrongu003eButu003c/strongu003e. Itu0026#39;s recommended to add u003ccode class=”prettyprint”u003egit secret hideu003c/codeu003e command to your u003ccode class=”prettyprint”u003epre-commitu003c/codeu003e hook, so you wonu0026#39;t miss any changes.u003c/liu003enu003cliu003eNow decrypt files with u003ccode class=”prettyprint”u003egit secret revealu003c/codeu003e command. It will ask you for your password. And youu0026#39;re done!u003c/liu003enu003c/olu003ennu003cpu003eCheck out u003ca href=”https://sobolevn.github.io/git-secret/#usage” rel=”nofollow”u003edocsu003c/au003e for more information.u003c/pu003en”,”tags”:[“bash”,”zsh”,”git”],”hearts”:3,”upvotes”:3,”created_at”:”2016-05-08T19:45:47.627Z”,”user”:{“id”:142145,”name”:null,”avatar”:{“url”:”https://coderwall-assets-0.s3.amazonaws.com/uploads/user/avatar/142145/4660275.jpeg”},”title”:”Software Developer”,”location”:”Russia, Moscow”,”country”:null,”city”:null,”state_name”:null,”company”:””,”about”:””,”team_id”:null,”api_key”:null,”admin”:null,”receive_newsletter”:false,”receive_weekly_digest”:false,”last_ip”:5,”last_email_sent”:null,”last_request_at”:”2016-05-09T23:01:06.765Z”,”created_at”:”2016-03-31T12:20:35.705Z”,”updated_at”:”2016-05-09T20:42:50.656Z”,”username”:”sobolevn”,”email”:”mail@sobolevn.me”,”encrypted_password”:”$2a$10$Nt9IaFf3qxgjXsn0D2EcM.m0CXUO6P/khJCAd7QYrtxCPYsH2DWEi”,”confirmation_token”:null,”remember_token”:”05aad37b6b5ecabcb15c0f4137e2286f21f630f2″,”skills”:[“python”,”elixir”,”javascript”],”github_id”:null,”twitter_id”:null,”github”:”sobolevn”,”twitter”:””,”color”:”#f0720f”,”karma”:1,”banned_at”:null,”marketing_list”:null,”email_invalid_at”:null}}}


Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/8bIhbdyhYvA/store-your-private-data-inside-a-git-repository

Original article

Rack: Open-Source PaaS on AWS

README.md

Build Status

Convox Rack is open source PaaS built on top of expert infrastructure automation and devops best practices.

Rack gives you a simple developer-focused API that lets you build, deploy, scale and manage apps on private infrastructure with ease.

Private and Secure

Rack runs in an isolated VPC that only you and your team have access to. Application builds take place in a single-tenant build service, and the resulting Docker images are stored in a private ECS Container Registry. Application secrets are stored in S3, encrypted with KMS, a hardware security module. Application logs are archived in CloudWatch LogsGroups.

Your network is isolated, your platform is single-tenant, and your application data never leaves your AWS account.

Simple and Reliable

Apps run as Docker containers on ECS with HTTP access through ELBs. This architecture is modern, simple and provably reliable and scalable.

Container Logs are extracted from Docker with its native APIs and log drivers. Docker daemon options are minimally changed to avoid observed log rotation problems.

Logs are stored in CloudWatch Logs for archival and search, and Kinesis for streaming. Lambda subscribers extract metrics and forward to 3rd party systems. This is simple and cost effective for any volume of logs.

Complex and experimental things like overlay networking, persistent container volumes, and distributed file systems are simply not supported at the moment.

All throughout the stack we aim to leverage managed services and mature systems to accomplish tasks at hand. AWS offers the vast majority of infrastructure services and Docker the vast majority of runtime functionality.

Easy to Maintain

Platform updates are automatically applied with the convox rack update command.

Updates are executed with CloudFormation, so you can be confident that they will be safely executed.

Some updates are simple Rack API changes that will roll out in seconds.

Some updates are base security updates like a new AMI, Linux Kernel, or Docker engine. These are rolled out one instance at a time and are guaranteed to not cause application downtime.

Some updates are infrastructure migrations. For example, ECR is still in limited availability. When it does become available, a future convox rack update will safely migrate your clouds over to it.

Open Source

Rack is open source and free (as in beer and in speech) to use. You can look at the source code to audit how it configures your AWS account. You you fork it and modify. You can contribute your ideas and patches back to the project so we can all share.

Philosophy

The Convox team and the Rack project have a strong philosophy about how to manage cloud services. Some choices we frequently consider:

  • Open over Closed
  • Integration over Invention
  • Services over Software
  • Robots over Humans
  • Shared Expertise vs Bespoke
  • Porcelain over Plumbing

Installation Quick Start

You need an AWS account and access credentials, the Convox CLI, and 10 minutes.

# Create and pass AWS access keys to the installer. These should be temporary keys and can be deleted after the install.

$ export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
$ export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# Download and install the convox CLI for your platform

$ curl -Ls https://install.convox.com/osx.zip > /tmp/convox.zip
$ unzip /tmp/convox.zip -d /usr/local/bin

# Install Rack. You may be interested in options like `--region us-west-2`

$ convox install
...

Success, try `convox apps`

See the Getting Started Guide for more instructions.

Development Quick Start

You need a Rack installed on AWS, a laptop with the Convox CLI, Go, and Docker, jq, and the Rack repo to run and develop the Rack API locally.

# Copy Rack AWS credentials and resource names to your development environment

$ STACK_NAME=$(convox api get /system | jq -r .name)
$ WEB_PID=$(convox api get /apps/$STACK_NAME/processes | jq -r '.[] | select(.name == "web") | .id' | head -1)
$ convox exec $WEB_PID env --app $STACK_NAME > .env

# Check out the Rack golang package

$ go get github.com/convox/rack/...
$ cd $GOPATH/src/github.com/convox/rack

# Start Rack locally in Docker

$ docker-machine start default
$ convox start
RUNNING: docker build -t convox-icytafnqqb /Users/noah/go/src/github.com/convox/rack
web      | running: docker run -i --name rack-web...
web      | [negroni] listening on :3000

# Log into the development server

$ convox login ($docker-machine ip default)

See the Development Guide for more instructions to develop, contribute and release changes for Rack and related components.

Contributing

License

Apache 2.0 © 2015 Convox, Inc.


Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/eUO9Ug78Px0/rack

Original article

Newspaper IT employees ‘angry as hell’ over foreign workers

For McClatchy Company IT employees who will lose their jobs once their work is moved to India, there are fury and questions.

As many as 150 IT employees at the chain, which runs some 30 newspapers, will be losing their jobs. (See: “Newspaper chain sending IT jobs overseas.”)

A government form, called the Labor Condition Application (LCA), is being posted on bulletin boards at the offices of various newspapers in the chain. This form alerts workers that at least one H-1B worker is being used.

Photographs of some of these notices, posted at the Miami Herald, one of the newspapers owned by McClatchy, were sent to Computerworld.

To read this article in full or to leave a comment, please click here


Original URL: http://www.computerworld.com/article/3067814/it-careers/newspaper-it-employees-angry-as-hell-over-foreign-workers.html#tk.rss_all

Original article

Newspaper Chain CEO ‘Pleased’ To Announce IT Plan, Then Fires Tech Staff

dcblogs writes from a report on Computerworld: The McClatchy Company, which operates a major chain of newspapers in the U.S., is moving IT work overseas. The number of affected jobs, based on employee estimates, range from 120 to 150. The chain owns about 30 newspapers, including The Sacramento Bee, where McClatchy is based; The Fresno Bee, The News and Observer in Raleigh, N.C., The State in Columbia, S.C. and the Miami Herald. In a letter sent to the chain’s IT employees in late March, McClatchy CEO Patrick Talamantes detailed all the improvements a contract with the outsourcing firm, India-based Wipro, will bring, but buries, well down in the letter what should have been in its lead paragraph: There will be cutbacks of U.S. staff. The letter received by McClatchy’s IT employees from Talamantes begins by telling them [the company] is “pleased to unveil our new IT Transformational Program, a program designed to provide improved service to all technology users, accelerated development and delivery of technology solutions and products, variable demand-based technology resources and access to modern and cutting-edge skills and platforms.” Seven paragraphs down in the letter, he lowers the boom: “As we embark on the implementation phase, there will be a realignment of resources requiring a reduction in McClatchy technology staff.” IT employees thought they were part of the solution to McClatchy’s tech direction, not the problem. Said one IT employee: “This has taken us all by surprise. I’m not saying that we felt untouchable as they have been doing layoffs for the past 10 years, but being part of IT we felt that we had a big part in what happens” in the company. Employees are now training their replacements.


Share on Google+

Read more of this story at Slashdot.


Original URL: http://rss.slashdot.org/~r/Slashdot/slashdot/~3/5fU5LPsyKls/newspaper-chain-ceo-pleased-to-announce-it-plan-then-fires-tech-staff

Original article

Show HN: Hackchain – Continuous Bitcoin-Inspired CTF Competition

NPM version

Alpha version

Continuous bitcoin-inspired capture-the-flag competition.

Preamble

A hackchain server was running in a cloud. Some hacker has installed the
client for it:

$ npm install -g hackchain

Hacker has also requested a server info:

$ hc-client --info
{ lastBlock: '4e9c8600ca954bbfd88a1ca8715e5cf5a751a8e5945802912086e632bec85e1f',
  nextBlockIn: 17,
  nextCoinbaseIn: 85817,
  'proof-of-work-complexity': 17 }

$ hc-client --leaderboard
===== Current top transactions =====
NOTE: It is important to use both hash and index to steal a transaction
[ { hash: '61d9faa5dc429c8eb4f00835f285b3a5f7022f8b557432a7af542d0b778bc14e',
    index: 4,
    value: '1500000000' },
    ... ]

“I wonder if I can capture some of these coins…”, she thought.

Description for Hackers

The server is running bitcoin-like blockchain with the main difference that the
blocks are issued automatically every 5 minutes. One may request the latest
block hash either by using --info argument of the hc-client, or by running:

curl https://api.hackcha.in/

The whole point of this “continuous CTF competition” is to capture someone else’s
coins and protect them. It is very close to CTF competitions, but
participants compete with each other instead of attacking some predefined
software.

New coins are minted only once every 24 hours, so hackers are encouraged to
steal coins from each other. Current leaderboard (list of unspent coins) can be
found by using --leaderboard argument of hc-client, or by running:

curl https://api.hackcha.in/leaderboard

Being very similar in structure to bitcoin blockchain, hackchain provides an
opportunity to learn about bitcoin internals, and most importantly have some
fun!

While recommended to read in order, one may skip all sections except
Capturing, where the process of capturing (stealing) coins is
described in detail.

Community

Feel free to join #hackchain IRC channel on freenode server to
discuss things with other hackers.

Block

Blocks have a link to the parent block (or a genesis block with the hash
0000000...., all zeroes), and a list of at least one transaction (TX). First
TX in a block is called a coinbase and (in contrast to bitcoin) can be spent
by anyone, unless its output value is 0.

Block may be inspected using --block argument of the hc-client:

<Block: b1e6483...
   parent: 6017999...
   txs: [ <Coinbase: 735c742...
      v=1
      inputs: [ <Input hash: 6017999...
          index: -1
          script: > ]
      outputs: [ <Output value: 2500000000
          script: > ]> ]>

Raw hex data may be fetched by running:

curl https://api.hackcha.in/v1/block/<hash>

Spec for the binary encodings of all structures is available below.

TX

Every transaction has at least one input and output.

Each input has a hash of input TX, index of output in that TX, and script
to capture it. (See “Capturing” section below).

Each output has a value number of coins, and script to prevent capturing
these coins.

TX cannot spend more coins than it gets from the inputs, but it can spend less.
The difference is called fee and is added to the coinbase of the block where
TX is stored.

TX may be inspected using --tx argument of the
hc-client:

<TX: 10319ac...
    v=1
    inputs: [ <Input hash: 699eb0e...
        index: 0
        script: > ]
    outputs: [ <Output value: 2500000000
        script: > ]>

Raw hex data may be inspected by running:

curl https://api.hackcha.in/v1/tx/<hash>

Capturing

In order to capture someone’s coin (or coinbase), the attacker must implement an
input script that will be able to defeat the output script of the TX.

Scripts are written is RiSC-16 (Ridiculously Simple Computer) instruction
set and are running in a shared memory space of 0x10000 16-bit words. Yes, you
read it right, the code is living in the same space, and the scripts are allowed
to modify each other.

The process:

  1. Spending TX (the one that you sent) hash is loaded to 0x0 offset of the
    memory
  2. output script is loaded to 0x1000 offset of the memory and executed
    until irq yield/irq success, or until it executes more than
    100 * 1024 opcodes (if so – coin is captured, and further steps are
    skipped)
  3. If irq success was executed in step 2 – coin is captured and the process
    ends. If irc yield was executed – proceed to step 4
  4. input script is loaded to 0x2000 offset of the memory
  5. One opcode of output is executed
  6. If any irq ... was executed – the process ends with captured coin
  7. One opcode of input is executed
  8. If any irq ... was executed – steps 7-8 are replaced by no op
  9. If number of opcodes executed in output after step 4 exceeds 1024 * 1024:
    process terminates, and coin is not captured

Scripts

Quoting RiSC-16, there are 8 different 16-bit registers (r0, …, r7),
and 10 different instructions:

  • add rA, rB, rC – Add contents of regB with regC, store result in regA
  • addi rA, rB, imm – Add contents of regB with imm, store result in regA
  • nand rA, rB, rC – Nand contents of regB with regC, store results in regA
  • lui rA, imm – Place the 10 ten bits of the 16-bit imm into the 10 ten bits
    of regA, setting the bottom 6 bits of regA to zero
  • sw rA, rB, imm – Store value from regA into memory. Memory address is formed
    by adding imm with contents of regB
  • lw rA, rB, imm – Load value from memory into regA. Memory address is formed
    by adding imm with contents of regB
  • beq rA, rB, imm – If the contents of regA and regB are the same, branch to
    the address PC+1+imm, where PC is the address of the beq instruction
  • jalr rA, rB – Branch to the address in regB. Store PC+1 into regA, where PC
    is the address of the jalr instruction.

They are encoded just as they are described in a paper.

Additional opcodes are added in hackchain:

  • irq success – terminate thread (see capturing too), encoded
    as 0xe001 word in big endian
  • irq yield – yield execution to input script (see
    step 2 above), encoded as 0xe081 word in big endian

NOTE: Reading value of r0 always returns 0 for your convenience!

Additional opcode-combos are available using the assembler in this repo:

  • jmp label-name – generate short (within 64 opcodes) relative jump to the
    specified label
  • farjmp rA, label-name – generate far absolute jump to the specified label.
    NOTE: rA register will be overwritten to store the absolute offset
  • bind label-name – bind specified label to the current opcode offset
  • lea rA, label-name – load label’s absolute address into the rA register
  • codeOffset – change code offset. Absolutely needed when
    using farjmp in code that doesn’t start at 0x0000 memory offset
  • movi rA, – will generate two opcodes lui nd addi
  • nop – will generate add r0, r0, r0
  • data 0xabcd – put the raw 16-bit word instead of an instruction

Examples:

Spending TX with hc-client

asciicast

It is possible to generate and send TX using hc-client. In order to do this,
a yaml-formatted tx-name.tx file must be created:

version: 1
inputs:
  - hash: 'a1dd41f1efd2498dd8126684fe164d22d6188046b1c71a7d5325c2158965237b'
    index: 0
    script:
      - irq success
outputs:
  - value: '2500000000'
    script:
      - irq yield
      - irq success

(See examples/ for more various TX examples)

NOTE: script arrays have string values. , or separators may be used
between opcode and arguments, and between arguments. Arguments are either:

  • rN – register input/output, where N is a number from 0 to 7
  • N – immediate value, where N is a decimal integer
    (either positive or negative)
  • string – anything that does not fit into one of two bullet points above.
    Usually used in irq opcodes (irq success, irq yield).

Afterwards, one may execute:

$ hc-client --spend tx-name.tx

It will parse file, generate TX, confirm it, and send it to server. If the
server will accept the TX, the confirmation will be printed. If the server will
reject the TX, a (hopefully) meaningful error message will be printed.

NOTE: While TXs are accepted immediately, they are not available for spending
until the server will mint a new block. Please check output of
hc-client --info to get the time until the next block.

Debugger

asciicast

While some scripts may be easy to follow, others may definitely require more
detailed investigation. This is where internal debugger may come out handy:

$ hc-debug --tx examples/tx/debug.tx

Or alternatively, if you’d like to debug output script that it is not in the
chain yet:

$ hc-debug examples/debugger/prog1.yaml

NOTE: yaml file with the contents of both scripts and TX hash, must be
supplied to debugger. See debugger examples

Binary Format

All values are in Big Endian.

Block

[ 32-bit number ] version
[ 32 bytes      ] parent sha256 hash
[ 32-bit number ] TX count
...               TXs

TX

[ 32-bit number ] version
[ 32-bit number ] input count
[ 32-bit number ] output count
...               inputs
...               outputs

Input

[ 32 bytes      ] sha256 hash of input TX
[ 32-bit number ] input index
...               script

Output

[ 8 bytes       ] big endian big number
...               script

Script

[ 32-bit number ] size of binary data below
...               binary opcodes for RiSC-16

Additional Server endpoints

$ curl https://api.hackcha.in/help | jq .
{
  "/": "information about server and last block",
  "/help": "this message",
  "/leaderboard": "list of currently unspent transactions",
  "/v1/block/(hash)": "GET block data",
  "/v1/tx/(hash)": "GET/POST transaction data",
  "/v1/tx/(hash)/block": "GET the hash of transaction's block",
  "/v1/tx/(hash)/(output index)/spentby": "GET the hash of spending tx"
}

Bugs

If any bugs, please file an issue. We will make sure to figure it out!

LICENSE

This software is licensed under the MIT License.

Copyright Fedor Indutny, 2016.

Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the
“Software”), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to permit
persons to whom the Software is furnished to do so, subject to the
following conditions:

The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
USE OR OTHER DEALINGS IN THE SOFTWARE.


Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/nMekzGSjGeU/

Original article

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: