18F launches cloud.gov

October 9, 2015

Tagged /

how we work
/

devops
/

our products
/

by

Bret Mogilefsky

18F is shipping products left and right lately. Every Kid in a
Park
, College
Scorecard
,
and
Federalist
have all debuted in the last month, and we’ve got more on the way. Other
teams might ask how we are shipping so many products, so close together,
with enough resilience to stand up to the traffic generated by the
President’s weekly address. Do we have an army of infrastructure people
on each one? Are we compromising on security? The answer is no. Instead,
we’ve had a small team tackling the core infrastructure issues in an
effort to enable our small development teams to improve delivery of 18F
products.

Boat-builders don’t launch ships by backing a trailer down a boat ramp.
Every boat they make is going to get launched, so they use a shipyard to
make it as easy as possible to build right near the water and get it
launched quickly and easily, even at battleship scale.

At 18F, we’ve developed cloud.gov, a shipyard
aimed at ensuring our teams can get even the smallest of boats in the
water in a production-worthy state from day one of development.

Scaling infrastructure expertise and reducing grunt work

Previously, infrastructure meant dealing with data centers, procuring
racks of hardware, flushing out single points of failure, cabling, and
managing baroque networking. Now, providers like Amazon Web Services,
Google Compute Engine, and other cloud vendors have commoditized that
infrastructure into something that you can buy rather than building and
managing yourself. This Infrastructure as a Service (IaaS) allows teams
to work more effectively and focus their time on problems that are
unique to the organization.

But even with IaaS in our toolbox, infrastructure experts are needed in
order to best manage, configure, and secure these IaaS resources. Those
experts need to ensure security-hardened operating system versions are
in use, and that vulnerability scans and software updates are happening
regularly. They need to understand how traffic gets routed from the
outside world and balanced across our hosts to deal with surges of
traffic. The government domain further requires them to have compliance
expertise in order to ensure the service being delivered satisfies a
byzantine regulatory
framework
, and then
generate a mountain of documentation to prove it to other people.

At 18F, we want our teams to stay small and quick but still deliver
best-practice services that can stand up to punishment. A core challenge
has been reducing the need for those highly-skilled infrastructure
resources to be on every one of our teams. We could have focused on
scaling up a centralized infrastructure team to look after all of these
concerns for all of our development teams, but that is not viable in the
long term. So instead we have focused on enabling people with broad and
shallow development expertise to accomplish things that would normally
require specialized experts.

The magic happens when an infrastructure team encapsulates their
expertise, and then exposes that expertise as a service which can be
used directly by developers
. This is what’s known as
“Platform-as-a-Service” (PaaS), and it’s a force-multiplier that bridges
that gap between small service teams and advanced infrastructure
skillsets, while keeping your headcount under control. 18F has built on
the open source project Cloud Foundry
to create our own PaaS that we call cloud.gov.

Creating a feedback loop

Creating cloud.gov has had a tremendous effect for our teams. The job of
the infrastructure team is shifting from “trying to look after all the
detailed infrastructure work on all the teams” to “provide spot
support and consultancy directly when teams run into trouble using
cloud.gov, then use what was learned to increase cloud.gov’s
capabilities.” Meanwhile, the development teams can incorporate advanced
operational capabilities without focusing a big portion of their efforts
on them.

This results in a feedback loop where the infrastructure team steers the
development of cloud.gov in the direction of making common irritations
go away. It’s that agile, user-centered iteration loop we strive for in
all our products, only the users in this case are development teams.

Giving those teams more time to work on their boat and less time
worrying about the boat launch allows 18F to keep our teams small, our
products robust, and our launches frequent.

Getting your own shipyard

We’re now exploring whether 18F’s cloud.gov meets the needs of several
federal agencies who are participating in a cloud.gov pilot program. We
plan to see what works, what doesn’t work, and fix any process
bottlenecks that pop up, and then hope to roll the service out more
broadly.

If you’re interested in cloud.gov, be sure to
drop your email address in the form located at https://cloud.gov, or
drop by our #devops-public Slack channel to
chat about it.


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

Original article

Just Enough Bitcoin for Ethereum

Time sure does fly! A new generation of programmers are already leapfrogging over Bitcoin and directly into Ethereum. These programmers may never have taken much interest in cryptocurrencies, but they’re drawn to Ethereum by its provisioning for trustless transactions of arbitrary (turing-complete!) complexity. While I can’t blame them for wanting to jump right into Ethereum, Ethereum derives a huge share of its underlying technology directly from Bitcoin. This series of articles will describe just enough of Bitcoin for budding Ethereum developers to better understand how Ethereum works under the hood, then begin to explore some routes by which new Ethereum devs can begin developing contract-orientation just like they developed their sense of object-orientation back in the day.

This is part one of a four part series. Part one, “Just Enough Bitcoin for Ethereum”, will focus on understanding Bitcoin. Part 2, “Ethereum: Bitcoin Plus Everything”, will focus on the ways in which Ethereum extends Bitcoin’s blockchain technology.

  1. Just Enough Bitcoin for Ethereum

The Blockchain

A blockchain is fundamentally a public record of state changes. Anybody can audit a blockchain’s state changes over time and prove for themselves with mathematical certainty whether those transactions were made in accordance with the blockchain’s rules. In the case of Bitcoin, those rules are simple: Bitcoins can’t be double-spent, and their origin must be traceable back to the mining of a valid block (more on mining later). To begin our journey, I recommend reading the Bitcoin whitepaper even if you know nothing about cryptography. We’ll loop back to the cryptographic underpinnings afterwards. The Bitcoin whitepaper is short, and only the first six sections are of real interest to us.

Cryptographic Underpinnings of Blockchain Transactions

As somebody with absolutely no background in cryptography, I found myself confused beginning with the white paper’s description of transactions. We should understand that this is a scheme designed to prove ownership over an asset at a given time by tracing that asset’s history of owners up to the present. But what’s a public key? Hashing? How do these help us to prove ownership of an asset? If you’ve never taken a cryptography class, watch the videos from Khan Academy below for a good high-level description of these important functions.

(Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System)

Now let’s look back at the white paper’s transaction diagram. Here we are hashing both Owner 2’s public key and the previous transaction (in which the Bitcoin entered Owner 1’s possession) into a single digest (the output of the hashing function). This digest is then signed with Owner 1’s private key. In the future, anyone can verify Owner 2’s claim on that Bitcoin by inputting the state change she/he insists occurred to a signature verification algorithm: a sum of Bitcoin and Owner 2’s public key (signifying a transfer of that sum to Owner 2), Owner 1’s public key (signifying that this transfer of Bitcoin originated from Owner 1), and the transaction’s signed form (a digest available publically on the blockchain, recorded there when the transaction took place). Only if the exact state change Owner 2 specifies was indeed signed with Owner 1’s private key will Owner 1’s public key assert the signed transaction digest’s validity relative to the signed transaction on-chain. This process can be repeated recursively going back to the Bitcoin’s origin to prove the complete ownership chain is valid.

You probably have a lot of questions at this point and are already considering edge cases — how does the ownership chain begin? How are specific sums of Bitcoin specified for transfer? Amazingly, there’s not much more of Bitcoin you need to understand for Ethereum’s sake. Next we’ll cover sections three through six of the whitepaper and figure out how some of those edge cases are resolved.

The Role of Mining in Creating Network Consensus on the Blockchain

All bitcoin transactions are broadcast to the entire network, and these transactions are collected by miners who verify those transaction’s validity (essentially using the method described previously) and include all valid transactions into a “block.” The contents of the block are then hashed with an incrementing random number (called a “nonce”) until the resulting output contains a certain number of leading zeroes. The network dynamically adjusts the requisite number of leading zeroes (or the “difficulty”) so that a block is mined every 10 minutes on average. Because the results of hashing algorithms are unpredictable, finding a valid hash which the rest of the network will accept requires both luck and CPU power. The more computational power one possesses, the greater their chances of finding a valid hash before anyone else in the network.When a valid block is “mined,” it is broadcast to and tested by the rest of the network. The other nodes test whether the included state transitions make sense given the most-recent canonical block, that all the transaction signatures pass for valid and that the block and the provided nonce hash to a valid digest before accepting the block as the newest canonical network state. The block is then added to the head of the existing “chain” of previously mined blocks in each node’s local database.

How does the ownership chain begin? The Bitcoin protocol specifies that every block is allowed to include a transaction of 25 BTC to the block miner, in which those 25 BTC are created out of thin air. This incentivizes miners to support the network. A Bitcoin can be verified as non-counterfeit if its ownership chain can be traced back to one of these special transactions. Indeed, this is the only way that new Bitcoin can be created.

Bitcoin is safe so long as at least 51% of the computational power for all the nodes connected to the network is controlled by honest, non-colluding users. A malicious user controlling 51% of the network who pays for his coffee with Bitcoin could drink his brew and then mine a block (starting at the state just before his transaction) which fraudulently omitted his coffee purchase. Even if the network had gotten a few blocks ahead of him by the time he started mining his fraudulent chain, with 51% of the network’s horsepower he would inevitably catch up. Because the Bitcoin protocol requires that the longest chain be accepted as canonical, the malicious user would get away with his theft even if there existed abandoned subtrees of the blockchain suggesting his deceit.

Extra Credit: UTXO in Bitcoin

In Bitcoin, one’s holdings do not comprise a pool of infinitely divisible currency units from which to withdraw and deposit. Instead, Bitcoin users deal in “unspent transaction outputs” (UTXO). If a miner wants to spend some of their freshly-minted 25 BTC on a 1 BTC coffee, they have to specify the entire 25 BTC (a UTXO) as the transaction’s input, and specify two outputs for the transaction: one output which sends one BTC to the vendor’s address, and a second output specifying 24 BTC be sent back to the purchaser’s address as “change”. To buy another coffee, that 24 BTC comprises a single UTXO. UTXOs which are combined in a transaction input to exchange for more expensive items are received by the vendor as a new, single UTXO. Ethereum does not use UTXO — it’s account balances are divisible.

You now have all the knowledge you need to understand the fundamentals of how the Bitcoin blockchain works. It’s head-spinning stuff! Don’t feel bad if you don’t totally get it yet: try sleeping on it for a few days and it’ll start coming together in your dreams. Once it does, you might be able to begin imaging how something a lot like the Bitcoin blockchain could be used to verify the public outputs of arbitrarily complex computations when the inputs and program code are publicly shared as well. In fact, that’s what we’ll explore in part II of this series. See you then!

Stay tuned for the next part in Mike’s series, “Ethereum: Bitcoin Plus Everything”.

Written by Mike Goldin & Designed by Eva Shon


Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/4Dm_OgCSZtg/time-sure-does-fly-ed4518792679

Original article

Add interactive documentation to your JavaScript apps with Intro.js

Add easy-to-absorb, interactive user documentation to your JavaScript
apps with Intro.js. Learn from a sample tour implementation how to demonstrate
your application’s features the modern way from within the app’s
UI.


Original URL: http://www.ibm.com/developerworks/opensource/library/wa-interactive-doc-javascript-introjs-bluemix-trs/index.html?ca=drs-

Original article

WordPress Brute Force Attacks Using Multiple Passwords Per Login Via XML-RPC

An anonymous reader writes: Online security firm Sicuri note a vertical rise in brute force attacks against WordPress websites using Brute Force Amplification, where a thousand passwords can be submitted within the scope of a single login attempt. The company notes that disabling the protocol is likely to interfere with the functionality of many plugins which rely on it. The Stack reports: “Sicuri note that most of the BFA calls are targeting the WordPress category enumerating hook wp.getCategories, and are targeting the ‘admin’ username, along with predictable default usernames. Sicuri recommend blocking system.multicall requests via a Web Access Firewall if available, but note that so many WordPress plugins depend on the point of vulnerability xmlrpc.php that blocking access to that functionality may interfere with normal operation of the site. The iThemes security system offers functionality to specifically disable XML-RPC as well, but this also requires a check against normal functioning of the site.”


Share on Google+

Read more of this story at Slashdot.


Original URL: http://rss.slashdot.org/~r/Slashdot/slashdot/~3/TS-LWLTJibE/wordpress-brute-force-attacks-using-multiple-passwords-per-login-via-xml-rpc

Original article

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

Up ↑

%d bloggers like this: