text:
# @requestnetwork/request-node

`@requestnetwork/request-node` is a package part of the [Request Network protocol](https://github.com/RequestNetwork/requestNetwork).
This package allows you to run a full Request Node.

Request Nodes are the basic servers used to allow any user to communicate with the Request Network protocol, these servers abstract the complexity of the storage layer for the users. The users can easily create a request or execute an action on a request by sending messages to the Node.

The Request Node runs the two bottom layers of the Request Network protocol:

- **Data-access layer**: Indexes request transactions and batches them into blocks.
- **Storage layers**: Persists data from Data-access layer.

Therefore, the Node receives request transactions from users, batches them into blocks and persists them into the storage.

Once received by the Node, other request actors connecting to this Node can directly read the request transaction before it is persisted into the storage layer.

To use Infura to connect to an Ethereum node, get an Infura token on [infura.io](infura.io) and
use as provider `"NETWORK_YOU_WANT.infura.io/v3/YOUR_INFURA_TOKEN"`.

## Usage

The users can interact with a Request Node either by using the official [Client-side Library](/packages/request-client.js) or by sending manual HTTP requests to the API exposed by the server.

### API

The API has the following endpoints:

#### persistTransaction

Persists a request transaction and make it available for the other actors of the request.

```
POST /persistTransaction {BODY}
```

##### Body

| Field           | Type           | Description                                                                                | Requirement   |
| --------------- | -------------- | ------------------------------------------------------------------------------------------- | ------------- |
| transactionData | {data: string} | Data of the request transaction from the [transaction layer](/packages/transaction-manager) | **Mandatory** |
| channelId       | string         | Channel used to group the transactions, a channel is used to represent a request            | **Mandatory** |
| topics          | string[]       | Topics to attach to the channel to allows the retrieval of the channel's transactions       | Optional      |

##### Example

```
curl \
	-d '{"channelId": "channelExample", "topics":["topicExample"], "transactionData":{"data": "someData"}}' \
	-H "Content-Type: application/json" \
	-X POST http://localhost:3000/persistTransaction
```

##### Success 200

| Field  | Type   | Description              |
| ------ | ------ | ------------------------ |
| meta   | Object | Metadata of the response |
| result | {}     | Empty object             |

##### Error

| Code | Description                                            |
| ---- | ------------------------------------------------------ |
| 422  | The input fields of the request are incorrect          |
| 500  | The persistTransaction operation from DataAccess fails |

#### getTransactionsByChannelId

Get list of transactions corresponding to a specified channel id.

```
GET /getTransactionsByChannelId?{PARAMETER}
```

##### Parameter

| Field               | Type                       | Description                                                            | Requirement   |
| ------------------- | -------------------------- | ---------------------------------------------------------------------- | ------------- |
| channelId           | string                     | Channel used to search for transactions                                | **Mandatory** |
| timestampBoundaries | {from: number, to: number} | Timestamps to search for transations in a specific temporal boundaries | Optional      |

##### Example

```
curl -i "http://localhost:3000/getTransactionsByChannelId?channelId=channelExample"
```

##### Success 200

| Field  | Type                     | Description              |
| ------ | ------------------------ | ------------------------ |
| meta   | Object                   | Metadata of the response |
| result | {transactions: string[]} | List of transaction      |

##### Error

| Code | Description                                                    |
| ---- | -------------------------------------------------------------- |
| 422  | The input fields of the request are incorrect                  |
| 500  | The getTransactionsByChannelId operation from DataAccess fails |

##### Note

Since the Node doesn't implement a cache yet, all transactions have to be retrieved directly on IPFS.
As a consequence, this request can take a long time if the topic requested indexes many transactions.
This delay will be optimized with the implementation of a cache.

If you experience issues, look into the [Graph mode](#thegraph-mode).

#### getChannelsByTopic

Get transactions from channels indexed by a specified topic.

```
GET /getChannelsByTopic?{PARAMETER}
```

##### Parameter

| Field          | Type                       | Description                                                  | Requirement   |
| -------------- | -------------------------- | ------------------------------------------------------------ | ------------- |
| topic          | string                     | Topic used to search for channels                            | **Mandatory** |
| updatedBetween | {from: number, to: number} | Temporal boundaries when the channel has been lately updated | Optional      |

##### Example

```
curl -i "http://localhost:3000/getChannelsByTopic?topic=topicExample"
```

##### Success 200

| Field  | Type                                    | Description                                |
| ------ | --------------------------------------- | ------------------------------------------ |
| meta   | Object                                  | Metadata of the response                   |
| result | {transactions: {[channelId]: string[]}} | List of transaction indexed by channel ids |

##### Error

| Code | Description                                            |
| ---- | ------------------------------------------------------ |
| 422  | The input fields of the request are incorrect          |
| 500  | The getChannelsByTopic operation from DataAccess fails |

## Deployment

A Node can be deployed by anyone. Users interested by running their own node can do it with the following instructions:

### Installation

#### Through the npm executable

```bash
npm install -g @requestnetwork/request-node
```

This will allow you to run the node with

```bash
request-node start
```

#### Through the sources

The Request Node source must be downloaded from Github and executed with Node.js.

```bash
git clone https://github.com/RequestNetwork/requestNetwork.git
cd packages/request-node
npm install
npm run build
```

### Setup

#### IPFS private network

The Request Node uses IPFS to store and share transactions in a private network.
We use a private network to allow all nodes to connect to each other directly,
instead of having to navigate through the public IPFS network.

To setup your IPFS node to the private network, you can run the following utility script:

```bash
yarn init-ipfs
```

#### TheGraph mode

An alternative data access relies on a [Graph](https://thegraph.com/) node, for better indexing & performance.

To enable it, set the `GRAPH_NODE_URL` environment variable to a Graph node with the [Request Storage Subgraph](https://github.com/RequestNetwork/storage-subgraph) deployed and synced.

### Launch

#### Command line

A Request Node can be started locally with the following command:

```bash
npm run start <options>
```

or

```bash
request-node start <options>
```

All command line options are optional.

The options used to run the server are defined as follows:

1. The option is defined in the command line
2. If the option is not defined in the command line, it is defined by the value of its corresponding environment variable
3. If the environment variable is not defined, default value is used

Default values correspond to the basic configuration used to run a server in a test environment.

#### Options:

- `--port` Port for the server to listen for API requests
  - Default value: `3000`
  - Environment variable name: `$PORT`
- `--networkId` Id of the Ethereum network used
  - Default value: `0`
  - Environment variable name: `$ETHEREUM_NETWORK_ID`
- `--providerUrl` URL of the web3 provider for Ethereum
  - Default value: `http://localhost:8545`
  - Environment variable name: `$WEB3_PROVIDER_URL`
- `--ipfsHost` Host of the IPFS gateway
  - Default value: `localhost`
  - Environment variable name: `$IPFS_HOST`
- `--ipfsPort` Port of the IPFS gateway
  - Default value: `5001`
  - Environment variable name: `$IPFS_PORT`
- `--ipfsProtocol` Protocol used to connect to the IPFS gateway
  - Default value: `http`
  - Environment variable name: `$IPFS_PROTOCOL`
- `--ipfsTimeout` Timeout threshold to connect to the IPFS gateway
  - Default value: `10000`
  - Environment variable name: `$IPFS_TIMEOUT`
- `--headers` Custom headers to send with the API responses (as a stringified JSON object)
  - Default value: `'{}'`
  - Environment variable name: `$HEADERS`
    `--blockConfirmations` The number of block confirmations to consider a transaction successful
  - Default value: `2`
  - Environment variable name: `$BLOCK_CONFIRMATIONS`
- `--lastBlockNumberDelay` The minimum delay between getLastBlockNumber calls to ethereum network
  - Default value: `'10000'`
  - Environment variable name: `$LAST_BLOCK_NUMBER_DELAY`
- `--storageConcurrency` Maximum number of concurrent calls to Ethereum or IPFS
  - Default value: `'200'`
  - Environment variable name: `$STORAGE_MAX_CONCURRENCY`
- `--initializationStorageFilePath` Path to a file to persist the ethereum metadata and transaction index for faster initialization
  - Environment variable name: `$INITIALIZATION_STORAGE_FILE_PATH`
- `--logLevel` The maximum level of messages we will log
  - Environment variable name: `$LOG_LEVEL`
  - Available levels: ERROR, WARN, INFO and DEBUG
- `--logMode` Defines the log format to use
  - Environment variable name: `$LOG_MODE`
  - Available modes:
    - `human` is a more human readable log to display during development
    - `machine` is better for parsing on CI or deployments
- `--persistTransactionTimeout` Defines the delay in seconds to wait before sending a timeout when creating or updating a request
  - Default value: 600
  - Environment variable name: `$PERSIST_TRANSACTION_TIMEOUT`
- `--externalUrl` External url of the node (used to identified where the buffer data are stored before being broadcasted on ethereum)
  - Environment variable name: `$EXTERNAL_URL`
- `--graphNodeUrl` External url of the Graph node, if any. If specified, this will replace the traditional data access with the Graph implementation. Default is undefined. See [TheGraph mode](#thegraph-mode).
  - Environment variable name: `$GRAPH_NODE_URL`

#### Mnemonic

The wallet used to append data into Ethereum blockchain is generated with a mnemonic.

The environment variable `$MNEMONIC` need to be set to the corresponding mnemonic.

If the environment variable is not set, the default mnemonic is:

```
candy maple cake sugar pudding cream honey rich smooth crumble sweet treat
```

This mnemonic should only be used for testing.

### Docker

The Request Node can be deployed with Docker.
The Docker image is available on the [DockerHub](https://hub.docker.com/r/requestnetwork/request-node).
Please refer to the [RequestNetwork/docker-images](https://github.com/RequestNetwork/docker-images) repository
for instructions on how to use this image.

#### Docker for unpublished version

See instructions in [Dockerfile.dev](./Dockerfile.dev).

### Running fully locally

To run a Request Node locally for tests, make sure you have the necessary IPFS and Ethereum nodes available.

You can run the following steps to launch a fully local test Request Node:

#### 1. Clone the repository

```bash
git clone https://github.com/RequestNetwork/requestNetwork.git
cd requestNetwork
```

#### 2. Install and build all the dependencies.

Install IPFS Kubo (go-ipfs)
https://docs.ipfs.tech/install/command-line/#install-ipfs-kubo

```bash
yarn install
yarn build
```

#### 3. On a new terminal, launch a local IPFS node

```bash
ipfs daemon
```

#### 4. On a new terminal, configure your IPFS node to connect to the private Request IPFS network

```bash
cd packages/request-node
yarn init-ipfs
```

#### 5. Launch [ganache](https://github.com/trufflesuite/ganache-cli#installation) with the default Request Node mnemonic

```bash
ganache-cli -l 90000000 -p 8545 -m \"candy maple cake sugar pudding cream honey rich smooth crumble sweet treat\"
```

#### 6. Deploy the smart contracts on ganache

```bash
cd packages/smart-contracts
yarn deploy
```

#### 7. Run the Request Node

```bash
cd ../packages/request-node
yarn start
```

#### 8. Test

Open a browser and navigate towards: http://localhost:3000/status
You can see the details of your local Request & IPFS nodes.

## Contributing

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.
[Read the contributing guide](/CONTRIBUTING.md)

## License

[MIT](/LICENSE)

repository: RequestNetwork/requestNetwork

repo_name: RequestNetwork/requestNetwork


text:
# File Uploader

Upload file from local to remote in multithreading. Support Java 8+.

[https://github.com/tongyuantongyu/FileUploader-Java](https://github.com/tongyuantongyu/FileUploader-Java)

This project use Java to reimplement the protocol used by C++ version File Uploader.

This Project is now considered working, but may still require further development.

Use maven to build this project, or go to [Release](https://github.com/tongyuantongyu/FileUploader-Java/releases) to get precompiled binary.

license: MIT

repository: tongyuantongyu/FileUploader-Java

branch_name: refs/heads/master

extension: md

gha_language: Java

gha_license_id: MIT

license_type: permissive

repo_name: tongyuantongyu/FileUploader-Java


text:
## The Return of the Navigator

### Precis

The United Worlds is in a state of uproar following
charges against the Parnell Corporation for thetr
attempt to repress Knowledge of a new and superior
Jump Drive Controller, developed by the Tyrell
Corporation.

And as the- recriminations reach their peak, the
Navigator returns...

In the earliest days following the development of the
JISE device, Parnell attempted the abitious ‘Outreach’
project. Using Jump Drives more powerful than ever
before, coupled to the (then) new JSE, the three
‘Outreach’ ships were dispatched to star systems of the
outer core. All three vanished forever, along with their
crews... Until now.

Parnell’s understanding of Jump-Space was incorrect,
and the flight programs caused the ships to make
jumps of Nuge lengths at extreme DFs. When the
Navigator’s ship emerges from Jump-Space within the
gravity well of the planet the Marines are operating on,
he ejects in an EEV and is rescued by the Marines.

The Navigator is completely blind, a white film covering
his eyes, and yet has an uncanny Knowledge of almost
any subject. He also proves to be highly precient and
able to determine his location by some unfathomable
sense.

When the Marines discover from the appropriated
Parnell files that his ship was dispatched over three
hundred years previously, and that the Navigator was
a member of the original crew, suspicions are raised.
When he also proves able to determine jump
coordinates without any mechanical aid, the Navigator
is suddenly the most valuable commodity of all, and
almost every corporation wants him for their own ends.

He is captured, retrieved, and captured again
repeatedly over a number of months, despite the
Marine’s best attempts - yet each time manages to
escape, steal a jump-ship and navigate to wherever a
the Marines happen to be. He is later captured whilst
being accompanied to CMC HQ by CSM Turner.

Turner is found aboard the drifting Jump-Ship with no
memory of events’ following the capture of the
Navigator. Even use of a truth drug reveals nothing.

Finally, in a showdown with Vanessa Parnell herself,
the Navigator demands to see Victor Parnell (the head
of Parnell at the time the ‘Outreach’ ships were
launched) himself, despite her insistence that he died
of natural Causes almost three hundred years
previously. After a series of fights, Vanessa herself kills
the Navigator, and before she can be interrogared with
a truth drug, she apparently commits suicide.

An autopsy shows she died from massive brain
hemorages, Caused by an anti-capture device
embedded in her brain - but the remains of the device
show a more sinister aspect. Vanessa was being
controlled...

A video transmission is intercepted between a much
Older Stetto, a very old Turner and someone they call
Victor intimating that the three controlled Vanessa and
executed her when she became a liability.

::: callout callout-info
With split screen so you can see Turner and Stetto. These older versions of major characters are in fact the originals from which the younger Stetto (who committed Sepuku following his capture in Drive Wars), and CSM Turner were cloned.
:::

They also discuss how much the Marines know about the
‘Outreach’ project, and the Navigator, and the older
Turner appends a video of him torturing the younger.

::: callout callout-info
Shot in the interrogation following the capture of himself and the Navigator .
:::

The questions raised are answered in "Drive Wars III - The Mortality Syndrome".

gha_language: HTML


text:
---
layout: posts
categories:
  - Blog
image: https://user-images.githubusercontent.com/39436379/40982280-700c70f6-690f-11e8-9b13-6d523d030eb0.png
title: "An Introduction to the BlockDAG Paradigm"
tags:
  BASIS
---

>Source：https://blog.daglabs.com/an-introduction-to-the-blockdag-paradigm-50027f44facb

>Transtudy：https://github.com/DAGfans/TranStudy/blob/master/Blogs/An%20Introduction%20to%20the%20BlockDAG%20Paradigm.md
## An Introduction to the BlockDAG Paradigm

## 区块 DAG 范式入门

*Contrary to popular belief, using a DAG (directed acyclic graph) as a distributed ledger is not about removing proof-of-work mining, blocks, or transaction fees. It is about leveraging the structural properties of DAGs to potentially solve blockchain’s orphan rate problem. The ability of a DAG to withstand this problem and thus improve on scalability is contingent on the additional rules implemented to deal with transaction consistency, and any other design choices made.*

*与大众的普遍观点相反，将 DAG（有向无环图）用作分布式账本并不会消除工作量证明式的挖矿，也不会消除区块和交易手续费。它的目的是利用 DAG 的结构特性帮助解决区块链的孤块率问题。DAG 解决这个问题并且改进可扩展性的能力取决于为了处理交易一致性而实现的额外规则，以及其它设计上所作的选择。*

### Directed acyclic graphs

### 有向无环图

A DAG is not a novel concept or technology, and it is definitely not a consensus mechanism; it is purely a mathematical structure originating from centuries ago. Technically, a DAG is a graph with directed edges and no cycles (i.e., there is no path from a vertex back to itself).

DAG 并不是一个新概念或是技术，并且它当然也不是一个共识机制；它纯粹是起源于几个世纪前的一种数学结构。在技术上，DAG 是一种包含有向边但不含环（即没有一条可以从一个顶点出发然后又回到它自己的路径）的图。

![DAG](https://cdn-images-1.medium.com/max/1600/1*aYmhytXcO6yxNpatmPwIIA.png)

In the context of distributed ledgers, a blockDAG is a DAG whose vertices represent blocks and whose edges represent references from blocks to their predecessors. Evidently, in a blockDAG, blocks may have several predecessors instead of just one; this will be described in more detail below. First, let us recall the orphan rate problem.

在分布式账本的环境中，区块 DAG 一种有特殊含义的 DAG。在这种 DAG 中，顶点代表区块，边代表区块对它们父辈的引用。显然，在区块 DAG 中，区块可能有多个父辈，而不是只有一个；下文会对此进行详细描述。首先，让我们回顾一下孤块率问题。

### Blockchain’s orphan rate problem

### 区块链的孤块率问题

There are many barriers to blockchain scalability, including processing speeds, disk I/O, RAM, bandwidth, and syncing new nodes. While these limitations can be addressed with improved hardware and technology, a major barrier exists on the protocol level: the orphan rate. Orphans are blocks that are created outside the longest chain due to unavoidable network propagation delays.

有许多因素制约着区块链的可扩展性，包括处理速度、磁盘 I/O、RAM、带宽，以及新节点的同步（译注：即新节点刚加入网络时将整条区块链下载同步到自己本地的过程）。虽说可以通过改善硬件和技术来突破这些限制，但一个最主要的瓶颈是在协议层面：孤块率。孤块是指由于不可避免的网络延迟而在最长链以外创建的区块。

Accelerating block creation and/or increasing block sizes increases the orphan rate: by the time a new block propagates throughout the network, other new blocks which do not reference it are likely to be created. It is well established that a high orphan rate amounts to compromised security; the more honest blocks that end up outside the longest chain due to spontaneous forks, the less secure is the chain. ^1

加快区块创建速度以及／或者增大区块大小会增大孤块率：在一个新区块传播遍网络之前，很可能会有其它新的不引用它的区块被创建出来。孤块率增大会导致安全性降低，这是公认的；如果有越多的诚实区块因为自然分叉的原因导致自己不在最长链中，那么这条链就越不安全。^1 （译注：这里的自然分叉是指由于协议本身的特性和网络延迟导致的分叉，而非攻击导致的分叉。在最长链规则下，分叉越多，攻击者为了使自己成为最长链而需要的算力就越小，因此最长链就越不安全。比如在有三条分叉的情况下，攻击者只需超过全网三分之一的算力即可攻占最长链。因此从协议本身的角度来讲，自然分叉越少越好。）

Blockchain protocols typically impose a maximum block size and constant block creation rate to accommodate the network propagation and minimize orphans. This artificial limit of transaction throughput and lower bound on latency (in Bitcoin’s case, to 3–7 transactions per second and tens of minutes confirmation times) is a hard pill for blockchains to swallow — while it impedes on-chain scaling, it guarantees that spontaneous forks and orphans are rare and, therefore, that the main chain is secure. DAG protocols, however, may deal with orphans in other ways.

区块链协议一般会规定一个最大区块大小和一个常数的出块率从而应对网络延时并且将孤块的数量降到最低。这种对交易吞吐量和等待时间下限的人工限制（在比特币的情况下，这个限制是每秒3至7个交易和数十分钟的确认时间）对区块链来说是一副苦药丸——它阻止了链上扩容，但保证了自然分叉和孤块极少出现，因此主链是安全的。然而 DAG 可以通过其它方式处理孤块问题。

### The blockDAG paradigm

### 区块 DAG 范式

The notion of a fork is organically absorbed in the DAG framework, so it seems worthwhile to consider if a DAG could do better than the chain/linked list structure of blockchains. Accordingly, with Satoshi’s proof-of-work system as the starting point, we need to make one change to the mining protocol in order to yield a blockDAG: blocks may reference multiple predecessors instead of a single parent. A canonical way to extend the ledger is to have blocks reference all tips of the graph (that their miners observe locally) instead of referencing the tip of the single longest chain, as in Satoshi’s original protocol.

DAG 框架有机地吸收了分叉这一概念，所以看上去 DAG 是否可以比链式／链表结构的区块链做得更好这件事情是值得我们考虑的。于是，以中本聪的工作量证明系统为基础，为了生成一个区块 DAG，我们需要对挖矿协议做出一个改变：区块可以引用多个父辈，而非一个单一的父亲。一种典型的扩展账本的方式是让区块引用（产生区块的挖矿者在本地能看到的）图中的所有末端，而非依照中本聪的原始协议只引用最长链的末端。

![blockDAG](https://cdn-images-1.medium.com/max/2000/1*YJgJTzHlnrXrDU_ddsWtAA.png)

In a canonical blockDAG ledger, new blocks reference all tips of the graph (blocks that have not yet been referenced) that their miners see locally. As in a blockchain, blocks are published immediately.

在一个典型的区块 DAG 账本中，新区块引用它们的挖矿者在本地看到的图中的所有末端（即还未被引用的区块）。和在区块链中一样，区块会被立即发布。

However, unlike a blockchain which, by construction, preserves consistency (every block in the chain adds transactions that are consistent with its predecessors in the chain), a blockDAG incorporates blocks from different “branches” and so may contain many conflicting transactions. Because of this, a DAG, or blockDAG, cannot be considered a “solution” or “novel approach” or “new protocol” in and of itself. Instead, a blockDAG is a framework for devising consensus protocols that may (or may not) be as secure as and more scalable than chain-based protocols. ^2

然而，和区块链不同的是，区块链在构建时会一直维护着一致性（链中的每个区块添加的交易都与链中的父辈一致），而区块 DAG 包含了来自不同“分支”的区块，所以可能包含许多冲突交易。因此，DAG 或是区块 DAG 本身并不能被认为是一个“解决方案”或是“新方法“或是”新协议“。区块 DAG 只是一个用来设计共识协议的框架，而基于它设计的协议与链式协议相比可能（也可能不）具有同等的安全性和更高的扩容性。^2

We therefore need a method to recover consistency; in other words, a blockDAG system requires replacing Satoshi’s longest chain rule with a new consensus protocol.

因此我们需要一种方法来恢复一致性；换句话说，区块 DAG 系统需要用新的共识协议来取代中本聪的最长链规则。

#### Consensus via ordering

#### 通过排序达成共识

Observe that if a distributed system achieves consensus on the order of all events in it, then we can easily extend this agreement to achieve consensus on the state — we simply iterate over all transactions according to the agreed order, and accept each transaction that is consistent with those accepted so far. This method preserves consistency by construction.

如果一个分布式系统对系统中所有事件的顺序达成共识，我们就可以很容易地将这个共识扩展到状态的共识——只需要简单地按照达成共识的顺序遍历所有交易，并且接受那些与已经被接受的交易一致的交易。这种方法在构建区块链的过程中就一直维护着一致性。

译注：注意作者在这里用的词是 accept，即“接受”。这个词容易与 confirm 即“确认”混淆。实际上两者的定义很模糊，在不同上下文会有不同解读。在有的上下文中，“确认”等同于 finality，笼统地说是指系统达到一个比较稳定的状态；在有的上下文中则是特指被多个区块“接受”，即交易所在的区块成为了多个区块的祖宗。至于“接受”的具体意思，还要看主语是什么（宾语是交易）。如果主语是节点，则一般指节点对接收到的交易进行校验后，认为交易合法并将其加入本地账本。如果主语是网络，则一般和“确认”意思相同，只不过是指首次“确认”。如果主语是用户，则代表的是用户的主观预期，比如用户可能认为如果交易被两个区块“接受”了，或者说成为了两个区块的合法祖宗，那交易就是安全的。原文此处“接受”的主语应该是节点，因此意思即指节点对交易的合法性进行校验后，将交易加入本地账本。在此处，交易合法性还包含了交易所隐含的历史交易顺序是否与系统中已达成共识的顺序相一致的意思。这里仅仅是指交易被节点“接受”。至于具体怎样的标准才能算作交易被系统“确认”，则视具体协议而定。

We are left with the task of defining an ordering protocol on all events in the system — in our context, on all blocks in the DAG — in a way that will be agreed upon, eventually, by all nodes.

我们现在要做的就是为系统中的所有事件——在我们的上下文中，就是 DAG 中的所有区块——定义一个排序协议。所有节点都会遵从这个协议从而在区块顺序上最重达成共识。

The natural topology of a DAG already induces a partial ordering over the blocks: if there is a path from block X to block Y in the DAG, then block Y was provably created before block X and so should precede X in the global order, and vice versa. Thus, we only need to define an order over blocks created in parallel, i.e. any set of blocks such that there is no path that connects them.

DAG 的自然拓扑本身就已经为区块引入了偏序排序：若在 DAG 中有一条路径从区块 X 到区块 Y，即可证明区块 Y 是在区块 X 之前被创建的，因此在全局排序中应该排在 X 前面，反之亦然。因此，我们只需要为并行创建的区块，也就是相互之间没有路径相连的区块所组成的集定义一种顺序。

This paradigm began with the blockDAG-based protocols developed out of the Hebrew University ([Inclusive](http://www.cs.huji.ac.il/~yoni_sompo/pubs/15/inclusive_full.pdf), [SPECTRE](http://www.cs.huji.ac.il/~yoni_sompo/pubs/17/SPECTRE.pdf), and [PHANTOM](https://eprint.iacr.org/2018/104.pdf)); these protocols each define an algorithm that outputs an order over the DAG’s blocks, iterates the DAG by that order, and eliminates transactions that conflict with previous ones. (Actually, SPECTRE does something slightly weaker, but that’s a topic for a separate blog post.)

这种范式起源于耶路撒冷希伯来大学开发的基于区块 DAG 的协议（[Inclusive](http://www.cs.huji.ac.il/~yoni_sompo/pubs/15/inclusive_full.pdf)、[SPECTRE](http://www.cs.huji.ac.il/~yoni_sompo/pubs/17/SPECTRE.pdf)，和 [PHANTOM](https://eprint.iacr.org/2018/104.pdf)）；这些协议分别定义了自己的算法，每个算法都对 DAG 中的区块进行排序，并按顺序遍历 DAG，消除与已经被遍历过的交易相冲突的交易。（实际上，SPECTRE 做的事情弱一些，不过这需要另写一篇单独的博文来论述。）

#### Advantages of blockDAGs

#### 区块 DAG 的优势

BlockDAG protocols such as SPECTRE and PHANTOM circumvent the problems associated with high orphan rates. This comes with many advantages:

SPECTRE 和 PHANTOM 这样的区块 DAG 协议规避了与高孤块率相关联的问题。这就带来了很多好处：

1\. It allows for confirmation times on the order of seconds, at least when there are visible double-spends and conflicts

1\. 确认时间可以以秒计算，至少是在有可见的双花和冲突交易时

2\. It allows for a large transaction throughput, limited only by the network backbone and endpoints’ capacity; as a derivative, it implies low fees

2\. 交易吞吐量可以变得很大，只受限于网络条件和终端能力；这样衍生出的好处是手续费会降低

3\. It contributes to mining decentralization by allowing for roughly 100,000 blocks per day, which reduces the incentive to join a mining pool

3\. 因为每天可以创建大约 100,000 个区块，所以矿工加入矿池的动机也会变弱，这进一步促成了挖矿去中心化

4\. It avoids the risk of orphaning, which comes with many additional benefits (such as Layer Two compatibility)

4\. 规避了孤块的风险，从而带来很多额外好处（比如与第二层兼容）（译注：第二层是指侧链或链下的解决方案，即在主链之上，新建一层辅助的平台和协议。比如[闪电网络](https://lightning.network/)，具体可参考《[区块链水平扩展：第二层网络](https://www.jianshu.com/p/8b5327c6d273)》。）

5\. It eliminates selfish mining by rewarding all blocks without discriminating between on-chain and off-chain blocks

5\. 通过奖励所有区块，消除链上和链下区块的差别，从而消除自私的挖矿行为

We will expand on each of these points and how SPECTRE and PHANTOM achieve them in future blog posts.

我们会在未来的博客文章里对上面的每一点进行具体论述，并讲述 SPECTRE 和 PHANTOM 是如何做到上面这几点的。

### BlockDAGs vs. blockless DAGs

### 区块 DAG vs. 无区块 DAG

Almost every single DAG-based cryptocurrency on the market (IOTA, Byteball, Nano, etc.) has deviated from Satoshi’s blockchain paradigm, not only by using the DAG structure, but also in economic design: some have relegated mining to their users, some have eliminated proof-of-work mining altogether, many have no transaction fees, and practically all have no blocks, chaining together individual transactions. These design decisions may work in a DAG system, but they are characteristics independent of DAGs. In fact, these projects’ use of a DAG is probably their least defining characteristic.

市场上几乎每种基于 DAG 的加密货币（IOTA、字节雪球、Nano，等等）都偏离了中本聪的区块链范式。这种偏离不仅体现在使用 DAG 结构上，还体现在经济学层面的设计上：有的将挖矿委托给用户，有的完全去除了工作量证明挖矿，许多货币没有交易手续费，并且实际上都没有区块——它们将一个个交易直接连在一起。虽然这些设计决策可以用在 DAG 系统中，但它们的特性和 DAG 完全无关。实际上，这些项目可能只用到了 DAG 特性的很小一部分。

The rising popularity of these DAG systems has heavily influenced the community’s perception of DAGs. On the one hand, there are the fervent supporters who tout DAG technology as “blockchain 3.0”, and on the other, the skeptics who dismiss it as vaporware. Almost all, however, praise or criticize the economic design choices of existing DAG protocols, which have nothing to do with DAGs.

这些 DAG 系统的兴起很大程度上影响了社区对 DAG 的看法。一方面，狂热支持派将 DAG 技术吹捧为“区块链3.0”；另一方面，怀疑论者对其不屑一顾。可是几乎所有人赞扬或批评的都是现存 DAG 协议在经济层面的设计决策，而这和 DAG 根本毫无关系。

For instance, in a recent Q&A, renowned blockchain expert Andreas Antonopoulos described DAGs as “an alternative consensus mechanism” opposed to proof-of-work. “If you don’t have decentralized proof-of-work mining, you don’t really need blocks,” Antonopoulos says. “You can just chain transactions together, which is the basis of directed acyclic graphs.”

比如，在最近的一个问答中，著名比特币专家 Andreas Antonopoulos 将 DAG 描述为和工作量证明相对的“另一种共识机制”。“如果你没有将工作量证明挖矿去中心化，你其实并不需要区块。” Antonopoulos 说道，“你只需要直接将交易连起来，这就是有向无环图的基础。”

[点击查看 Andreas Antonopoulos 的问答视频](https://youtu.be/lfgMnbb5JeM)

But, as explained above, DAGs are not about replacing proof-of-work or blocks. DAGs are merely a mathematical structure that happen to be used by several projects that deviate from Satoshi’s proof-of-work system. In contrast, blockDAGs are the applications of DAGs to a Nakamoto-based system (in particular, with proof-of-work), only redesigning the data structure and consensus layer.

但是上文已经解释过，DAG 并不是要取代工作量证明或区块。DAG 只是一种数学结构。只是这种数学结构恰好被一些偏离了中本聪的工作量证明系统的项目所使用。与此相反，区块 DAG 是要将 DAG 应用在基于中本聪的系统中（并且特别要强调的是，区块 DAG 使用工作量证明），只是将数据结构和共识层重新设计了一遍。

Bram Cohen of BitTorrent and Chia hits closer to the mark with [this scathing tweet](https://twitter.com/bramcohen/status/958535459969249280?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fblog.daglabs.com%2Fmedia%2F50531e63836a47557cd7203b3bf388ce%3FpostId%3D50027f44facb):

比特流（BitTorrent）和 Chia 的创始人布拉姆·科恩（Bram Cohen）[在推特上发表的尖锐评论](https://twitter.com/bramcohen/status/958535459969249280?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fblog.daglabs.com%2Fmedia%2F50531e63836a47557cd7203b3bf388ce%3FpostId%3D50027f44facb)更接近本质：

> A Directed Acyclic Graph is a data structure, not a kind of proof of work. It's used in Git, dating from 2005, and comes from long before that. It is not novel, notable, or exciting.
>
>   -- Bram Cohen, 12:00 PM - Jan 31, 2018

> 有向无环图（DAG）是一种数据结构，而不是一种工作量证明。早在2005年它就被用在 Git 中。它的起源则更是久远。DAG 并不是什么新奇的、引人注目的，或是让人兴奋的东西。
>
>  ——布拉姆·科恩，2018年1月31日中午12点

Indeed, a DAG is purely a structural alternative to a chain — and a chain is also not novel, notable, or exciting. What made Satoshi’s system novel is its overall design: proof-of-work mining, blocks, transactions, and a protocol that reaches consensus in a permissionless system and incentivizes participation. BlockDAG systems like SPECTRE and PHANTOM generalize over Satoshi’s innovative design and achieve novelty through their unique consensus protocols for ordering the DAG in an irreversible way, thus avoiding the security-scalability tradeoffs brought on by orphans.

的确，DAG 和链的不同纯粹只是在结构上——并且链也不是什么新奇的、引人注目的，或是让人兴奋的东西。中本聪系统的新颖之处是在它的全局设计上：工作量证明挖矿、区块、交易，以及一个在缺乏许可的系统和需要依靠物质激励的参与环境中达成共识的协议。像 SPECTRE 和 PHANTOM 这样的区块 DAG 系统比中本聪的革新设计更为通用和创新的地方是在于，它们独特的共识协议对 DAG 的排序是不可翻转的，因此避免了孤块带来的安全性和扩容性之间的取舍问题。

### Footnotes:

### 脚注：

^1 For proofs of this statement see [[a]](https://eprint.iacr.org/2013/881.pdf)[[b]](https://eprint.iacr.org/2014/765.pdf)[[c]](https://eprint.iacr.org/2016/454.pdf)

^1 该论述的证明可参考 [[a]](https://eprint.iacr.org/2013/881.pdf)[[b]](https://eprint.iacr.org/2014/765.pdf)[[c]](https://eprint.iacr.org/2016/454.pdf)

^2 For example, if a DAG protocol sorts transactions by having those in the longest chain precede all others, it suffers from the same security-scalability tradeoffs of a blockchain.

^2 比如，如果一个 DAG 协议对交易进行排序时将最长链里的交易全部排在其余交易的前面，那它的安全性与扩容性的折衷关系就和区块链一样。

url: https://raw.githubusercontent.com/DAGfans/DAGfans.github.io/db5c7d868a17b315c7f6da4df50576e49a2a16e4/_posts/2018-06-05-An Introduction to the BlockDAG Paradigm.md


text:
# timewarp

[![Build Status](https://travis-ci.org/tobi-wan-kenobi/timewarp.svg?branch=master)](https://travis-ci.org/tobi-wan-kenobi/timewarp)
[![Code Climate](https://codeclimate.com/github/tobi-wan-kenobi/timewarp/badges/gpa.svg)](https://codeclimate.com/github/tobi-wan-kenobi/timewarp)
[![Test Coverage](https://codeclimate.com/github/tobi-wan-kenobi/timewarp/badges/coverage.svg)](https://codeclimate.com/github/tobi-wan-kenobi/timewarp/coverage)
[![Issue Count](https://codeclimate.com/github/tobi-wan-kenobi/timewarp/badges/issue_count.svg)](https://codeclimate.com/github/tobi-wan-kenobi/timewarp)

Supported Python versions: 2.7, 3.3, 3.4, 3.5, 3.6

`timewarp` is a small utility to snapshot and restore your virtual machines in cloud environments. Currently, only Amazon Web Services (AWS) EC2 is supported. It is primarily intended for developers that want to snapshot their instance before doing risky modifications during the development cycle.

I know it goes against the grain of the "virtual machines are cattle, not pets" paradigm of cloud computing, but we developers **do** get attached to our instances occasionally ;)

**IMPORTANT NOTE**: Please only use the tool in development accounts where the loss of resources such as volumes, instances, etc. does not have severe impact.

**IMPORTANT NOTE 2**: Please do *not* use this software in production environments, for two reasons:
1. AWS offers much superior means to keep your instances healthy (e.g. CloudFormation, Auto Recovery, Elastic Loadbalancing, etc.)
2. This is a *very* early alpha version of the software and might contain severe bugs. Among other disasters, this tool could inadvertently delete random snapshots, create random volumes and stop random instances. Having said that, I did my best to ensure this doesn't actually happen.

**IMPORTANT NOTE 3**: Due to the fact that this is a very early version, I urge you to test it with an unprivileged read-only user first to ensure it does not delete too much (as part of the recovery process, old volumes are detached and deleted, and instances might get stopped). To emphasize: If you use this tool incorrectly (or if it has stupid bugs), it might delete volumes or stop instances not intended for deletion! You have been warned.

Having said that, here's how you use it:

- "checkpoints" are point-in-time snapshots (I wanted to avoid the term "snapshot" as to not create a confusion between timewarp snapshots and AWS EC2 snapshots)
- "virtual machines" are instances
- The tool requires `boto3` to be installed and configured
- Required AWS permissions:
  - list snapshots
  - create snapshots (to create a checkpoint)
  - create volumes (to restore a checkpoint)
  - delete snapshots (to delete a checkpoint)
  - delete volumes (to restore a checkpoint, not required if you are using `--keep-volume`)
  - start/stop instances (to restore a checkpoint, not required if you manually stop the instance before restoring)
```
# list all checkpoints for a virtual machine
###########################################
$ timewarp ec2 list <instance id>

# create a new checkpoint
###########################################
$ timewarp ec2 create <instance id>
# optionally, you can also provide a name for the checkpoint:
$ timewarp ec2 create [-n|--name <name>] <instance id>

# restore a previous checkpoint - the checkpoint id is retrieved
# from the "list" command
###########################################
$ timewarp ec2 restore <instance id> <checkpoint id>
# when restoring a checkpoint, you can specify "-k" (or "--keep-volumes")
# to keep the volumes. Otherwise, the original volumes will be deleted.
$ timewarp ec2 restore -k <instance id> <checkpoint id>
# when restoring a checkpoint, you can specify "-c" (or "--current-checkpoint")
# to automatically create a checkpoint for the current state.
$ timewarp ec2 restore -c <instance id> <checkpoint id>
# restoring will NOT work if the instance is currently running (as it needs to
# be stopped for that). In order to automatically stop and restart the instance,
# specify "-f" or "--force" to the call:
$ timewarp ec2 restore -f <instance id> <checkpoint id>

# delete a list of timewarp checkpoints
###########################################
$ timewarp ec2 delete <instance id> <checkpoint id> <checkpoint id> ...
```

All commands also support a "dry-run" flag (`-d|--dry-run`) and a "verbose" flag (`-v|--verbose`). In dry-run mode, no destructive action (stopping a VM, deleting a snapshot, deleting or detaching a volume) **should** be performed - but as always: Please beware of bugs!

# Known restrictions and bugs
* Only EBS volumes are snapshotted
* "Delete on termination" settings for volumes get lost - **after a restore, your volumes will NOT be automatically deleted on instance termination anymore!** The reason for this: I couldn't figure out how to set this via boto3.
* The instance still has to exist (i.e. recovering a deleted instance is not possible using this tool)
* Completely untested alpha software

# Example usage
Here are some examples for a three-volume instance:

```
# dry-run a create (nothing happens)
$ timewarp -d ec2 create i-09eab02eb24cb9d1d
creating new snapshot from volume vol-0d585d48213213d01 for instance i-09eab02eb24cb9d1d
creating new snapshot from volume vol-0c48979c6b7df1514 for instance i-09eab02eb24cb9d1d
creating new snapshot from volume vol-0c79befcb7f50fb07 for instance i-09eab02eb24cb9d1d
$ timewarp ec2 list i-09eab02eb24cb9d1d
$ # no output
# actually create an unnamed checkpoint
$ bin/timewarp ec2 create i-09eab02eb24cb9d1d
$ timewarp ec2 list i-09eab02eb24cb9d1d
checkpoint-time checkpoint-id   checkpoint-name
2017-08-18 11:24:31+00:00       f0163084-db6b-4778-a5c3-e8fefac00c8e    None
# create a checkpoint named "test checkpoint"
$ timewarp ec2 create -n "test checkpoint" i-09eab02eb24cb9d1d
$ timewarp ec2 list i-09eab02eb24cb9d1d
checkpoint-time checkpoint-id   checkpoint-name
2017-08-18 11:34:07+00:00       0e8829e8-16dc-4b7c-b87a-b674e570398c    test checkpoint
2017-08-18 11:24:31+00:00       f0163084-db6b-4778-a5c3-e8fefac00c8e    None
# restore the unnamed snapshot, deleting the current volumes, but creating a backup of the current state
$ timewarp ec2 restore -f --current-checkpoint i-09eab02eb24cb9d1d f0163084-db6b-4778-a5c3-e8fefac00c8e
$ timewarp ec2 list i-09eab02eb24cb9d1d
checkpoint-time checkpoint-id   checkpoint-name
2017-08-18 11:57:32+00:00       8a44996a-da65-4a06-859e-8ef6c2f039b6    timewarp restore checkpoint
2017-08-18 11:34:07+00:00       0e8829e8-16dc-4b7c-b87a-b674e570398c    test checkpoint
2017-08-18 11:24:31+00:00       f0163084-db6b-4778-a5c3-e8fefac00c8e    None
# delete the automatic checkpoint
$ timewarp ec2 delete i-09eab02eb24cb9d1d 8a44996a-da65-4a06-859e-8ef6c2f039b6
$ timewarp ec2 list i-09eab02eb24cb9d1d
checkpoint-time checkpoint-id   checkpoint-name
2017-08-18 11:34:07+00:00       0e8829e8-16dc-4b7c-b87a-b674e570398c    test checkpoint
2017-08-18 11:24:31+00:00       f0163084-db6b-4778-a5c3-e8fefac00c8e    None
```

# Further plans
- Add more unit tests
- Roll back restore when an error occurs (e.g. start instance again)
- Add a parameter for asynchronous mode
- Upload to pypi
- Show instance id when listing checkpoints
- Provide more feedback during operation
- Bash completion
- Support for other clouds

repository: GaneshBabu-J/timewarp

repo_name: GaneshBabu-J/timewarp


text:
### Dashboard for JVM

#### Notes

- This dashboard is based on Google's [Ops Agent](https://cloud.google.com/stackdriver/docs/solutions/agents/ops-agent).
- The full list of metrics supported by the Ops Agent can be found [here](https://cloud.google.com/stackdriver/docs/solutions/agents/ops-agent/third-party/jvm#monitored-metrics).

|JVM GCE Overview|
|:------------------|
|Filename: [overview.json](overview.json)|
|This dashboard has 6 charts displaying `Classes Loaded`, `Threads`, `Garbage Collection Count`, `Garbage Collection Time`, `Heap Memory`, and `Non-Heap Memory`.|

repository: dknezicd/monitoring-dashboard-samples

gha_language: HCL

repo_name: dknezicd/monitoring-dashboard-samples


text:
iOS7-Parallax
============

An HTML based implementation of the iOS7 parallax feature.

An example of this tech can be seen [here](http://www.youtube.com/watch?v=ljoy4iAQwWw).

Currently, this implementation works fairly well but suffers from gimbal lock.


text:
# Apple launches new privacy website, but policies unchanged

Published at: **2019-11-06T14:29:33+00:00**

Author: **EndPlay**

Original: [WFXT](https://www.boston25news.com/news/apple-launches-new-privacy-website-but-policies-unchanged/1005678150?utm_source=homestream&utm_medium=site_navigation&utm_campaign=homestream_click)

CUPERTINO, Calif. (AP) - Apple is expanding its website on privacy with more explanations about its commitments, though its policies and practices aren't changing.
The new site Wednesday is part of Apple's ongoing push to distinguish itself from data-hungry, advertising-fueled rivals such as Google and Facebook.
Apple's privacy website is mostly a users' guide with papers on how to prevent apps and other third-party services from unnecessarily tracking users' location and behaviors.
The company's actual privacy policy hasn't changed.
Many of the new privacy enhancements were announced earlier as part of Apple's iOS 13 software update for iPhones. Changes include the ability to sign in to third-party services with an Apple ID account rather than Facebook's or Google's, plus more notices and warnings about apps tapping location data.

license: Unlicense

repository: dsadlollioygjmzvcxv/tdc-exported

repo_name: dsadlollioygjmzvcxv/tdc-exported


text:
## CAP theorem
>  In the presence of network partition, one has to choose between consistency and availability (tradeoff).

* Consistency: Every read receives the most recent write or an error
* Availability: Every request receives a (non-error)response - without the guarantee that it contains the most recent write
* Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped(or delayed) by the network between nodes

### Consensus
All non-faulty processes decide the same value(data consistency)

#### Model
* synchronous model
* asynchronous model

### Fischer-Lynch-Paterson (FLP) result：
> You can't do agreement in an AsynchronousMessagePassing system
> if even one crash failure is allowed, unless you argument
> the basic model in some way, e.g. by adding randomization or failure detectors.

### Challenge
* faulty processor
* Byzantine faults, weakest type of failure and the most difficult kind to deal with. Allow arbitrary failures including malicious faults
    1. failure to return a result
    1. return of an incorrect result
    1. return differing results to different parts of the system

## Solutions?

Common fault tolerant (unreliable processors, no malicious processors)
---
1. Paxos
1. Raft

Byzantine fault tolerance (Byzantine Generals' Problem, arbitrary failures)
---
1. Byzantine Paxos
1. Practical Byzantine Fault Tolerance Algorithm (PBFT)
1. Zyzzyva
1. Aardvark
1. RBFT

Proof Of Work
---
1. [Bitcoin POW]
1. [Cuckoo Cycle](https://github.com/tromp/cuckoo) adopted by aternity
1. [Equihash](https://github.com/tromp/equihash) adopted by Zcash

Proof Of Stake
---
1. [Ethereum Casper](https://github.com/tromp/equihash)
1. [Delegated Proof of Stake](http://docs.bitshares.org/bitshares/dpos.html)
1. [Cardano Ouroborous](https://www.cardano.org/en/ouroboros/)
1. [Algorand](https://eprint.iacr.org/2018/377)
1. [Tendermint](https://tendermint.com/)

Summary
---

|              | openness  | throughput | fault tolerance | Consumption | latency|
|:-------------|:----------|:-----------|:----------------|:------------|:-------|
| 2PC          | NO        |    Good
| Paxos        | Bad       |    Good
| Raft         | Bad       |    Good
| PBFT         | Bad       |    Good
| POW          | Good      |    Bad
| POS          | Good      |    Bad
| DPOS         | Medium    |    Medium
| Ouroborous   | Good      |    Medium


text:
---
layout: post
title: Exploiting a privileged zombie process handle leak on Cygwin
categories: [exploit]
tags: [cygwin, lpe, eop, windows]
description: A story about Cygwin local privilege escalation using privileged inherited handles of zombie processes
---

## Vulnerability ##

Two months ago, I was playing with Cygwin and I noticed that all Cygwin processes inherited dead process handles using [Process Hacker](https://wj32.org/processhacker/nightly.php):

![Process Hacker showing dead handles]({{ site.BASE_PATH }}/assets/media/CygwinProcessHacker.png "Process Hacker showing dead handles")

*Bash.exe* process spawned by SSH daemon after a successful connection **(1)** runs with a newly created token as limited test user.

Indeed, Cygwin SSHD worked at the time with an administrator account (*cyg_server*) emulating set(e)uid by creating a new user token using undocumented *NtCreateToken*.
See [Cygwin documentation](https://cygwin.com/cygwin-ug-net/ntsec.html) for more information about the change with version 3.0.

The same *bash.exe* process inherits 3 handles of non-existent processes with full access rights **(2)**.

Tracing the process creation and termination with [Process Monitor](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) during the SSH connection revealed that these leaked handles are actually privileged process **(3)** running as *cyg_server*.

## Exploitation ##

So what can we do with privileged zombie process handles, since we have full access (_PROCESS_ALL_ACCESS_) we can:

Access Right | Possible action
---- | ---
_OpenProcessToken_ | **FAIL** Access denied
_PROCESS_VM_OPERATION_ | **FAIL**: Any VM operation will fail because the process does not have a address space anymore
_PROCESS_CREATE_THREAD_ | **FAIL**: Same problem, no address space, creating thread in the process will NOT work
_PROCESS_DUP_HANDLE_ | **FAIL**: Access denied on DuplicateHandle (not sure why :D)
_PROCESS_CREATE_PROCESS_ | **SUCCESS**: Finally! Let's see how to use this privilege:

When creating a process, the attribute *PROC_THREAD_ATTRIBUTE_PARENT_PROCESS* in *STARTUPINFO* structure allows the calling process to use a different process as the parent for the process being created.
The calling process must have **PROCESS_CREATE_PROCESS** access right on the process handle used as the parent.

From Windows documentation: *Attributes inherited from the specified process include handles, the device map, processor affinity, priority, quotas, the process token, and job object.* **So the spawned process will use the privileged token thus it will run as cyg_server**:

![CMD running as cyg_server after exploit]({{ site.BASE_PATH }}/assets/media/CygwinExploit.png "CMD running as cyg_server after exploit")

This exploitation technique is not new and there are maybe other ways to exploit this case but I wanted to show a real world example of create process with parent handle instead of just posting about it. I find it cleaner than injecting a shellcode in a privileged process to spawn a process.

[Exploit source](https://gist.github.com/masthoon/6435384f8ee6c4dae25f263977347732)

## Fix ##

The vulnerability is now fixed with Cygwin version 3.0 thanks to the maintainers that were very responsive.

[Commit 1: Restricting permissions](https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=69cc7a068656b5c6ef07ca079a213f801e02e650;hp=0fb497165f8545470624012315aeaf37333c1ea2)

[Commit 2: Restricting permissions on exec](https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=5a0f2c00aa019de73a6077ca3017b594c43184a4;hp=c86b2f549bd099fdb56834d28a8103e8b9814e32)

[Commit 3: Removing the handle inheritance](https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=4d738e0f62403c3f1b082abf927aab00056230c5;hp=5a0f2c00aa019de73a6077ca3017b594c43184a4)


text:
# Breast Cancer Classifier
A simple neural network using pythons Scikit-Learn library to predict the degree of malignance in tumors on breast cancer patients.

# Other Neural Networks
Decision Tree (Bobby Chenkus)

https://github.com/BobbyChenkus/Breast-Cancer-Degree-of-Malignancy

Random Forest (Trey Gary and Nathaniel Small)

https://github.com/tgary1/Random-Forest

https://github.com/nsmal1/random-forest

repository: RezaSadeghiWSU/breast-cancer-classifier

branch_name: refs/heads/main

repo_name: RezaSadeghiWSU/breast-cancer-classifier


text:
---
layout: default
---

# 1996-11-21 - CAVE Report

## Header Data

From: John Young<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: a9d33d48b3f69fa92e98ec687a56ebe4c83b4c3506fcd65d8565d3528288ff07

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1996-11-21 03:47:29 UTC

Raw Date: Wed, 20 Nov 1996 19:47:29 -0800 (PST)

## Raw message

```
{% raw  %}From: John Young<EMAIL_ADDRESS>Date: Wed, 20 Nov 1996 19:47:29 -0800 (PST)
To<EMAIL_ADDRESS>Subject: CAVE Report
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

We've put the CAVE-based report at:

   http://jya.com/tr453.htm  (46 kb with 7 images)

CAVE = Cellular Authentication and Voice Encryption algorithm.

Nokia, for one, uses a CAVE algorithm to secure its latest toy.

{% endraw %}
```

## Thread

+ Return to [November 1996](/archive/1996/11)

+ Return to "[John Young <jya@pipeline.com>](/authors/john_young_jya_at_pipeline_com_)"

+ 1996-11-21 (Wed, 20 Nov 1996 19:47:29 -0800 (PST)) - CAVE Report - _John Young<EMAIL_ADDRESS>


text:
# Index
* [Argument assessment](#ArgumentAssessment)
* [API Reference](#APIReference)
	* [Argument assessment API](Argument-assessment-API)
	* {"[TBD: Assert assessment API](TBD_-Assert-assessment-API)"}
	* [Argument assessment extension](Argument-assessment-extension)
	* {"[TBD: Assert assessment extension](TBD_-Assert-assessment-extension)"}

## {anchor:ArgumentAssessment}Argument assessment
For further reading please consider [API Reference](#APIReference).

## {anchor:APIReference}API Reference

Guardly API is quite small, though very useful. Please refer to the dedicated documentation from the list below:
* [Argument assessment API](Argument-assessment-API)
* {"[TBD: Assert assessment API](TBD_-Assert-assessment-API)"}
* [Argument assessment extension](Argument-assessment-extension)
* {"[TBD: Assert assessment extension](TBD_-Assert-assessment-extension)"}

repository: rstroilov/guardly

repo_name: rstroilov/guardly


text:
microarray
==========

Scripts and tools for microarray specific tasks.

  * `annotate_probesets.py`: annotate probe set list based on probe set names
  * `best_exons.py`: average data for 'best' exons for each gene symbol in a file
  * `xrothologs.py`: cross-reference data for two species using probe set lookup

annotate_probesets.py
---------------------

Usage: `annotate_probesets.py OPTIONS probe_set_file`

Annotate a probeset list based on probe set names: reads in first column of
tab-delimited input file 'probe_set_file' as a list of probeset names and outputs
these names to another tab-delimited file with a description for each. Output file name
can be specified with the -o option, otherwise it will be the input file name with
'_annotated' appended.

Options:

    --version    show program's version number and exit
    -h, --help   show this help message and exit
    -o OUT_FILE  specify output file name

Example input:

    ...
    1769726_at
    1769727_s_at
    ...

generates output:

    ...
    1769726_at	Rank 1: _at : anti-sense target (most probe sets on the array)
    1769727_s_at	Warning: _s_at : designates probe sets that share common probes among multiple transcripts from different genes
    ...

best_exons.py
-------------

Average data for 'best' exons for each gene symbol in a file.

### Usage: ###

    best_exons.py [OPTIONS] EXONS_IN BEST_EXONS

Read exon and gene symbol data from EXONS_IN and picks the top three exons for
each gene symbol, then outputs averages of the associated values to BEST_EXONS.

Options:

    --version             show program's version number and exit
    -h, --help            show this help message and exit
    --rank-by=CRITERION   select the criterion for ranking the 'best' exons;
                          possible options are: 'log2_fold_change' (default), or
                          'p_value'.
    --probeset-col=PROBESET_COL
                          specify column with probeset names (default=0, columns
                          start counting from zero)
    --gene-symbol-col=GENE_SYMBOL_COL
                          specify column with gene symbols (default=1, columns
                          start counting from zero)
    --log2-fold-change-col=LOG2_FOLD_CHANGE_COL
                          specify column with log2 fold change (default=12,
                          columns start counting from zero)
     --p-value-col=P_VALUE_COL
                          specify column with p-value (default=13; columns start
                          counting from zero)
    --debug               Turn on debug output

### Description ###

Program to pick 'top' three exons for each gene symbol from a TSV file
with the exon data (file has one exon per line) and output a single
line for that gene symbol with values averaged over the top three.

'Top' or 'best' exons are determined by ranking on either the `log2FoldChange`
(the default) or `pValue` (see the `--rank-by` option):

 * For `log2FoldChange`, the 'best' exon is the one with the biggest
   absolute `log2FoldChange`; if this is positive or zero then takes
   the top three largest fold change value. Otherwise takes the bottom
   three.

 * For `pValue`, the 'best' exon is the one with the smallest value.

Outputs a TSV file with one line per gene symbol plus the average of
each data value for the 3 best exons according to the specified criterion.
The averages are just the mean of all the values.

### Input file format ###

Tab separated values (TSV) file, with first line optionally being a header
line.

By default the program assumes:

 * Column 1:  probeset name (change using `--probeset-col`)
 * Column 2:  gene symbol (change using `--gene-symbol-col`)
 * Column 13: log2 fold change (change using `--log2-fold-change-col`)
 * Column 14: p-value (change using `--p-value-col`)

Column numbering starts from 1.

### Output file format ###

TSV file with one gene symbol per line plus averaged data for the 'best'
exons, and an extra column which has a `*` to indicate which gene symbols
had 4 or fewer exons associated with them in the input file.

xrothologs.py
-------------

Cross-reference data for two species using probe set lookup

### Usage: ###

    xrorthologs.py [options] LOOKUPFILE SPECIES1 SPECIES2

### Description ###

Cross-reference data from two species given a lookup file that maps probe set
IDs from one species onto those onto the other.

`LOOKUPFILE` is a tab-delimited file with one probe set for species 1 per line in
first column and a comma-separated list of the equivalent probe sets for species 2
in the fourth column, e.g.

    ...
    121_at	7849	18510	1418208_at,1446561_at
    1255_g_at	2978	14913	1421061_a
    1316_at	7067	21833	1426997_at,1443952_at,1454675_at
    1320_at	11099	24000	1419054_a_at,1419055_a_at,1453298_at
    1405_i_at	6352	20304	1418126_at
    ...

Data for the two species are in tab-delimited files SPECIES1 and SPECIES2, where
the first column in each is a probe set ID (this is the only requirement).

The output consists of two files:

  * `SPECIES1_appended.txt`: a copy of `SPECIES1` with the cross-referenced data
    from `SPECIES2` appended to each line, and
  * `SPECIES2_appended.txt`: a copy of `SPECIES2` with the `SPECIES1` data appended.

Where there are multiple matching orthologs to a probe set ID, the data for each
match is appended onto a single line on the output.

Options:

    -h, --help  show this help message and exit
    --debug     Turn on debugging output
    --test      Run unit tests

repository: golharam/genomics

extension: markdown

repo_name: golharam/genomics


text:
Maze Solving Application README
---

Follow the below instructions to run the maze:
1. Install ([Node JS 6.10.3](https://nodejs.org/en/))
2. Pull latest master branch from Github ([Here](https://github.com/TimKrippner/MazeSolver))
3. Using your favorite shell client, navigate to the location of your newly pulled git repository.
4. Run command "node app.js"
5. In a web browser, navigate to ([LocalHost:10000](http://localhost:10000/))
6. Click Upload File
7. Navigate to a text based maze file of your choice. The git repository has 3 mazes located in the "mazes" directory. Highlight and click open.
    If for any reason the completed maze does not appear, restart the server and upload the maze again.
8. To attempt different mazes, turn off the server and repeat the process from step 4 down.

Special mention for coding examples: Fady Makram - Building a File Uploader with NodeJs. ([Fady Makram](https://github.com/FadyMak))

repository: TimKrippner/MazeSolver

repo_name: TimKrippner/MazeSolver


text:
---
layout: post
title: In Information Security, Trust Matters
date: 2013-01-11 13:55:00.000000000 -08:00
type: post
published: true
status: publish
categories: []
tags:
- Check Point
meta:
  _publicize_pending: '1'
author:
  login: phoneboy
  email<EMAIL_ADDRESS>  display_name: Dameon Welch
  first_name: ''
  last_name: ''
---
In a previous post, I asked if we could [trust no one](/2012/12/13/trust-no-one/) in Information Security. The reality is
that, at some point, we have to trust. We have to trust that we have the right policy in place. We have to trust our people to do the right thing. We have to trust our tools will do their job.

Of course, we should not blindly trust. We need to evaluate that our tools are doing their job, keeping the bad stuff out and enforcing the policy you've specified. We need to trust that our people are doing the right thing. Your tools are both enforcing the policy and educating the users about what the policy is, right? And, of course, you need to evaluate the policy to ensure it is both effective and in-line with business objectives.

If Information Security professionals spend all their time doubting everything, not only will they drive themselves crazy, but the real threats will get by.

Along these lines, The marketing folks at Check Point put together a video discussing trust and its very important role in Information Security.


text:
# [CfP] Deadline extended: Workshop on Research Objects (RO2019)
_Call for Papers_

Workshop on Research Objects (RO2019)
2019-09-24 at IEEE eScience 2019, San Diego, CA, USA
<http://www.researchobject.org/ro2019/>

## Timeline

* ~~2019-07-05 RO2019 submissions due: articles~~
* ~~2019-07-15 RO2019 submissions due: abstracts for oral presentation~~
* ~~2019-07-27 RO2019 Notification of acceptance~~
* ~~2019-08-30 Camera-ready papers due for accepted articles~~
* ~~2019-09-02 RO2019 submissions due: poster/demo abstracts~~
* ~~**2019-09-24** RO2019 at IEEE eScience 2019~~

## Research Objects

Scholarly Communication has evolved significantly in recent years, with an
increasing focus on Open Research, FAIR data sharing and community-developed
open source methods. A question remains on how to publish, archive and explore
digital research outputs.

A number of initiatives have begun to explore how to package and describe
research outputs, data, methods, workflows, provenance and structured metadata,
reusing existing Web standards and formats.

Such efforts aim to address the challenges of structuring multi-part research
outcomes with their context, handling distributed and living content and
porting and safely exchange what we collectively can call “Research Objects”
between platforms and between researchers.

## Call for Papers

In the workshop RO2019 we will explore recent advancements in Research Objects
and publishing of research data with peer-reviewed presentations, invited
talks, short demos, lightning talks and break-out sessions to further build
relationships across scientific domains and RO practitioners.

RO2019 welcomes submissions of:
 - abstracts for oral communication (~ 1-2 pages)
 - short research articles (~ 4-8 pages)
 - poster and demo abstracts (~ 1-2 pages)

on cross-cutting case studies or specific research on topics including, but not limited to:

- reproducibility
- scientific workflows
- provenance
- FAIR metrics
- platforms, infrastructure and tools
- research data lifecycles
- access control and secure exchange
- examples of exploitation and application
- executable containers
- metadata and annotations
- data packaging and formats
- credit, attribution and peer review
- big data and distribution
- scholarly communications
- alignments with community efforts
- domain-specific and cross-domain Research Objects.

## Submitting

Submitted abstracts and articles can be in a range of open formats (e.g. HTML,
ePub) and are particularly encouraged to be submitted in a FAIR research data
packing format.

Accepted articles will be included in the IEEE eScience 2019
proceedings. Submitted preprints will, upon acceptance, be made available as
Green Open Access on the RO2019 website with DOI links to the Zenodo record and
(where applicable) the published IEEE proceeding article.

It is a requirement that at least one author of each accepted submission
attends the RO2019 workshop at the IEEE eScience 2019 conference, where
registration fees applies.

Further details on submitting:
<http://www.researchobject.org/ro2019/submitting>

RO2019 encourages open peer review, and recommend that reviewers
are named and attributed; however reviewers may be anonymous if so
desired. Reviewers are welcome to publish their reviews using the
same guidelines as the research articles.

## Workshop organizers

* Carole Goble (The University of Manchester, UK)
* Raul Palma (Poznan Supercomputing and Networking Center, Poland)
* Stian Soiland-Reyes (The University of Manchester, UK; Apache Software Foundation)
* Daniel Garijo (University of Southern California, US)

For any questions, feel free to email the
RO2019 Workshop Organizers at
<EMAIL_ADDRESS>


text:
---
layout: post
title:      "IT'S ALIVE"
date:       2019-02-22 13:16:04 +0000
permalink:  its_alive
---

Building apps and writing code is what we do as developers on a daily basis. However just because we build an app and write hundreds or thusands of lines of code doesnt mean the world will be able to access it or even use the app. Most developers will leave notes for other developers to read through on how to access the data, start servers, run scripts, etc. This is great for other developers or engineers. However, this doesnt mean the average individual with zero experience will understand how to use the application or even get it running to see what the app can do. This is where Deployment comes in to play. Heroku provides developers with an easy to use deployment process that allows beginner level programmers deploy, manage, and scale their apps for the world to see/use.

The process of deploying to Heroku can be intidimidating for those who havent done it before or at least it was for me. One of the first steps I needed to do was to update my version of ruby. I previously was using `rvm 2.3.3` but any version higher than that one. I ran the  `rvm install 2.5.3`. After updating the ruby version was updated, I need to change a few of the gems in my rails application. First gem I changed was the `gem "sqlite3"` to the `gem "pg"`. Just like any other time the gem files is altered, the next step was to run `bundle install` to make sure those gem dependencies were installed and accessible in the application.

After reading through the documentation on the heroku website, I realized I needed to to alter my `database.yml` to work with Heroku. I replaced the contents of the file with the following documentation:
```
# PostgreSQL. Versions 9.1 and up are supported.
#
# Install the pg driver:
#   gem install pg
# On OS X with Homebrew:
#   gem install pg -- --with-pg-config=/usr/local/bin/pg_config
# On OS X with MacPorts:
#   gem install pg -- --with-pg-config=/opt/local/lib/postgresql84/bin/pg_config
# On Windows:
#   gem install pg
#       Choose the win32 build.
#       Install PostgreSQL and put its /bin directory on your path.
#
# Configure Using Gemfile
# gem 'pg'
#
default: &default
  adapter: postgresql
  encoding: unicode
  # For details on connection pooling, see Rails configuration guide
  # http://guides.rubyonrails.org/configuring.html#database-pooling
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

development:
  <<: *default
  host: localhost
  database: myapp_development

  # The specified database role being used to connect to postgres.
  # To create additional roles in postgres see `$ createuser --help`.
  # When left blank, postgres will use the default role. This is
  # the same name as the operating system user that initialized the database.
  #username: myapp

  # The password associated with the postgres role (username).
  #password:

  # Connect on a TCP socket. Omitted by default since the client uses a
  # domain socket that doesn't need configuration. Windows does not have
  # domain sockets, so uncomment these lines.
  #host: localhost

  # The TCP port the server listens on. Defaults to 5432.
  # If your server runs on a different port number, change accordingly.
  #port: 5432

  # Schema search path. The server defaults to $user,public
  #schema_search_path: myapp,sharedapp,public

  # Minimum log levels, in increasing order:
  #   debug5, debug4, debug3, debug2, debug1,
  #   log, notice, warning, error, fatal, and panic
  # Defaults to warning.
  #min_messages: notice

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  <<: *default
  host: localhost
  database: myapp_test

# As with config/secrets.yml, you never want to store sensitive information,
# like your database password, in your source code. If your source code is
# ever seen by anyone, they now have access to your database.
#
# Instead, provide the password as a unix environment variable when you boot
# the app. Read http://guides.rubyonrails.org/configuring.html#configuring-a-database
# for a full rundown on how to provide these environment variables in a
# production deployment.
#
# On Heroku and other platform providers, you may have a full connection URL
# available as an environment variable. For example:
#
#   DATABASE_URL="postgres://myuser:mypass@localhost/somedatabase"
#
# You can use this database configuration with:
#
#   production:
#     url: <%= ENV['DATABASE_URL'] %>
#
production:
  <<: *default
  database: myapp_production
  username: myapp
  password: <%= ENV['MYAPP_DATABASE_PASSWORD'] %>
```
You will notice that the database files for production have been altered to have myapp_production, development, etc. This is needed for the application to be able to run on the kerokju deployment and not need local server running within the terminal. After these files have been updated I needed to update the database that my app was going to utilize. This was achieved by running `rails db:create` and then `rails db:migrate`. After this was done, I merged by 2 heroku branch to the master branch to deploy through heroku. After successfully merging the branches I was able to deploy the app, update the url for the app on Github, and now anyone who chooses to, can access the app from GitHub.


text:
---
layout: post
title: Sheffield Devops - Feb 2019 Meetup
date: 2020-02-05
---

[Eventbrite Link](https://www.eventbrite.co.uk/e/sheffield-devops-february-2020-tickets-92687718461)

The next Sheffield Devops event takes place at the Ministry of Justice Sheffield Digital Studio on Thursday 13 February 2020 at 6pm.

Our event is generously hosted by the MoJ in their Digital Studio, and food/drinks provided by our regular sponsors Affecto Recruitment, and the first talk starting at 6:30pm.

We're striving for Sheffield Devops to be an inclusive event that is open to all. We operate a Code of Conduct and are happy to meet & greet people on arrival. Please drop us a message on Twitter if you have any queries or would just like a chat ahead of the event.

Schedule

* 18:00 - 18:30: Doors open
* 18:30 - 19:15: How the MoJ are enabling Digital Transformation using Kubernetes and Cloud Platform - Mike Willis
* 19:15 - 20:30: Break
* 19:30 - 20:15: Importance of great culture in engineering teams and how to grow it - Steve Wilson

## Venue

HMPPS Digital Studio,
Greenfield House,
32 Scotland St,
Sheffield
S3 7BS

Map: [https://goo.gl/maps/xqxb1jZkpxZcEuNk7]

## Sponsors

### MoJ Digital

MOJ Digital and Technology was set up to change the way that people access and use justice services. Our goal is to make the justice system simpler and quicker while saving public money.

These are exciting times at MOJ Digital and Technology. We have a clear vision - to develop a digitally-enabled justice system that works more simply for users.

As well as doing great work, we’re creating a place that’s great to do work in. We offer tip-top kit, brilliant training opportunities and support from expert colleagues. On top of that, you’ll find flexible working, an inclusive culture and a place where your opinion is valued.

To find out more about what we do and how we’re doing it, read our blog

https://mojdigital.blog.gov.uk/

### Affecto Recruitment

Affecto is a multi-disciplined, specialist technology recruitment business that focuses on permanent, interim and contract appointments across Yorkshire and The Midlands. We’ve spent years building our networks across IT from Development and Project Management to Infrastructure and Data Science. With such an intense battle for skills being fought, more and more organisations are looking to us to connect them with the people who can make a real difference.

[https://www.affecto.co.uk/](https://www.affecto.co.uk)

### CMS

CMS is proud to be a long term sponsor of Sheffield Devops. CMS is an international law firm with a specific sector focus on the technology and digital sectors. Ben Hendry, a partner in CMS’s Sheffield office said “We are passionate about supporting the growth of the Sheffield City Region. Like the Sheffield DevOps team, we want Sheffield to be the UKs next big technology hub, attracting the best tech businesses and talent from across the UK and beyond, and encouraging innovation. Supporting organisations like Sheffield DevOps is a vital part of this strategy and we are very much looking forward to working with both in order to achieve our common goal.”For more information on CMS’s technology focus click [here](https://cms.law/en/jurisdiction/global-reach/Europe/United-Kingdom/CMS-CMNO/TMT-Technology-Media-Telecommunications)

---

If you’d like to find out more about Sheffield Devops then head to [http://www.sheffielddevops.org.uk/](/) or talk to us on twitter [@sheffieldDevops](https://twitter.com/sheffieldDevops). We look forward to seeing you there!

[Code of Conduct](/code-of-conduct)

gha_language: SCSS


text:
# Python refactoring made easy in Sublime Text 3#
## Introduction ##
This plugin is designed to help [rope](https://github.com/python-rope/rope.git) users to refactor python codes. It generates a temporary rope script, which refactors your codes, and then it reloads the refactored codes in Sublime Text. This is a quick and dirty hack and may not work well for very complex codes.

## Refactor Methods Implemented ##
0. Create a rope project (Ctrl+Shift+N): You must create the rope project first before performing any following refactoring actions.
1. Undo last refactoring action (Ctrl+Shift+Z)
2. Redo last refactoring action (Ctrl+Shift+Y)
3. Rename a field
4. Rename a module
5. Transform a module to package with the same name
6. Change the signiture of a function/method
7. Extract method
8. Extract variable
9. Inline: Inline occurrences of a method/variable/parameter
10. Change a local variable to field
11. Introduce parameter to a function
12. Introduce constructor factory (select a class name to perform the refactoring)
13. Encapsulate field: Generate a getter/setter for a field and changes its occurrences to use them.
14. Use function: Try to use a function whenever possible
15. Move across module
16. Move attribute
17. Transform function to method object
18. Restructure

## Installation ##
Prerequisite: Install the [rope package](https://github.com/python-rope/rope.git) from PyPI.

1. Automatic installation via Package Control. Search for [PyRefactor](https://sublime.wbond.net/packages/PyRefactor) under Package Control.
2. Manual installation via github
Clone the git repository directly into the Packages folder

    git clone git@github.com:dnatag/PyRefactor.git

## Usage Guide ##
0. Create a rope project in the project level (Ctrl+Shift+N)
1. Use Cmd+Shift+P (Ctrl+Shift+P in Linux or Windows) and type Refactor to choose refactoring method
2. Under Tools Menu and then submenu Refactor to choose proper refactoring method

## Licence ##

You can use this under Simplified BSD License:

Copyright (c) 2014, Yi Xie All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

    Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
    Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

repository: dnatag/PyRefactor

gha_language: Python

repo_name: dnatag/PyRefactor


text:
---
layout: default
---

# 1994-02-01 - Privacy As Roadkill

## Header Data

From<EMAIL_ADDRESS>(Reynolds Griffith)

To<EMAIL_ADDRESS>Message Hash: d9e8543d7712993aa349a754dea99c0014c529e9493cf916bcec2d85a6954c21

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1994-02-01 15:15:28 UTC

Raw Date: Tue, 1 Feb 94 07:15:28 PST

## Raw message

```
{% raw  %}From<EMAIL_ADDRESS>(Reynolds Griffith)
Date: Tue, 1 Feb 94 07:15:28 PST
To<EMAIL_ADDRESS>Subject: Privacy As Roadkill
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

>Date: Mon, 31 Jan 1994 12:37:12 -0800 (PST)
>From: Dave Wren<EMAIL_ADDRESS>>Subject: Privacy As Roadkill
>To<EMAIL_ADDRESS><EMAIL_ADDRESS>>Errors-To<EMAIL_ADDRESS>>Sender<EMAIL_ADDRESS>>Reply-To<EMAIL_ADDRESS>>Precedence: bulk
>X-Mailing-List<EMAIL_ADDRESS>>
>
>---------- Forwarded message ----------
>Date: Sun, 30 Jan 1994 21:00:50 -0800
>From: "Brock N. Meeks"<EMAIL_ADDRESS>>To<EMAIL_ADDRESS>>Subject: Privacy As Roadkill
>
>
>
>Jacking in from a "Private No More" Port:
>
>Washington, DC -- If privacy isn't already the first victim of
>roadkill along the information superhighway, then it's about to be.
>
>A law enforcement panel addressing the Administration's Information
>Infrastructure Task Force Working Group on Privacy told a public
>meeting here last week that it wanted to "front load" the National
>Information Infrastructure with trap door technologies that would
>allow them to easy access to digital conversations;  eavesdropping
>on any conversation or capturing electronic communications
>midstream.
>
>But only for "the bad guys."  Us honest, hard working, law abiding
>citizens have nothing to fear from these law enforcement agencies
>selling out our privacy rights to make their jobs easier.  Nope, we
>can rest easy, knowing that child pornographers, drug traffickers
>and organized crime families will be sufficiently thwarted by law
>enforcement's proposed built-in gadgetry for the national
>information infrastructure.
>
>There's just a small problem:  Law enforcement agencies, any law
>enforcement agency, has yet to prove it needs all these proposed
>digital trap doors.  In fact, according to a U.S. Assistant
>Attorney appearing on the panel, "Right now most law enforcement
>personnel don't have any idea what the NII is."
>
>Gore Gives Go Ahead
>===================
>
>Panel members, representing the Justice Dept., FBI and U.S.
>Attorney's office, said that they took Vice President Gore's
>promise that the White House would work to ensure that the NII
>would "help law enforcement agencies thwart criminals and
>terrorists who might use advanced telecommunications to commit
>crimes," as tacit approval of their proposals to push for digital
>wiretap access and government mandated encryption policies.
>
>Gore buried those remarks deep in a speech he made in Los Angeles
>earlier this month when the Administration first fleshed out how it
>planned to rewrite the rules for communications in a newer, perhaps
>more enlightened age.  Those remarks went unnoticed by the
>mainstream press.  But readers here were forewarned.
>
>Fuck Ross Perot's NAFTA-induced "giant sucking sound."  That
>"thump" you just heard was Law Enforcement running over the privacy
>rights of the American public on its way to the information
>superhighway.  The real crime is that the collision barely dented
>the damn fender.
>
>This cunning and calculated move by law enforcement to install
>interception technologies all along the information superhighway
>was blithely referred to as "proactive" law enforcement policy by
>Assistant U.S. Attorney, Northern Dist. of California Kent Walker.
>Designing these technologies into future networks, which include
>all telephone systems, would ensure that law enforcement
>organizations "have the same capabilities that we all enjoy right
>now," Walker said.
>
>With today's wiretap operations, the Feds must get a court to
>approve their request, but only after supplying enough evidence
>warrant one.  But Walker seemed to be lobbying for the opposite.
>Giving the Feds the ability to listen in first and give
>justification later was "no big difference," he said. Besides, "it
>would save time and money."
>
>It's Us vs. Them
>=================
>
>For Walker privacy issues weighed against law enforcement needs are
>black and white, or rather "good guys" vs. "bad guys."   For
>example, he said the rapid rise of private (read: non-government
>controlled) encryption technologies didn't mean law enforcement
>would have to work harder.  On the contrary, "it only means we'll
>catch less criminals," he said.
>
>But if law enforcement is merely concerned with the task of "just
>putting the bad guys in jail," as James Settle, head of the FBI's
>National Computer Crime Squad states, then why are we seeing an
>unprecedented move by government intelligence agencies into areas
>they have historically shied from?  Because law enforcement
>agencies know their window of opportunity for asserting their
>influence is right now, right at the time the government is about
>to take on a fundamental shift in how it deals privacy issues
>within the networks that make up the NII, says David Sobel, general
>counsel for Computer Professionals for Social Responsibility
>(CPSR), who also spoke as a panel member.
>
>"Because of law enforcement's concerns (regarding digital
>technologies), we're seeing an unprecedented involvement by federal
>security agencies in the domestic law enforcement activities,"
>Sobel said.
>
>Sobel dropped-kicked this chilling fact from behind the closed
>doors of the Clinton Administration into the IITF's lap:  For the
>first time in history, the National Security Agency (NSA) "is now
>deeply involved in the design of the public telecommunications
>network."
>
>Go ahead.  Read it again.
>
>Sobel backs up his claims with hundreds of pages of previously
>classified memos and reports obtained under the Freedom of
>Information Act.  The involvement of the NSA in the design of our
>telephone networks is, Sobel believes, a violation of federal
>statutes.
>
>Sobel's also concerned that the public might soon be looking down
>the throat of a classified telecommunications standard being
>created.  Another move he calls "unprecedented," is that if the
>NSA, FBI and other law enforcement organizations have their way,
>the design of the national telecommunications network will end up
>classified and withheld from the public.
>
>Sobel is dead bang on target with his warnings.
>
>The telecommunications industry and FBI have set up an ad hoc
>working group to see if a technical fix for digital wiretapping can
>be found to make the Bureau happy.  That way, legislation doesn't
>need to be passed that might mandate such FBI access and stick the
>Baby Bells with eating the full cost of reengineering their
>networks.
>
>This joint group was formed during a March 26, 1992 meeting at
>FBI's Quantico, Va., facilities, according previously classified
>FBI documents released under Freedom of Information Act. The group
>was only formalized late last year, working under the auspices of
>the Alliance for Telecommunications Industry Solutions (ATIS).  The
>joint industry-FBI group operates under the innocuous sounding name
>of the Electronic Communications Service Provider Committee
>(ECSPC).
>
>The ECSPC meets monthly with intent of seeking a technological
>"solution" to the FBI's request for putting a trap door into
>digital switches that would allow them easy access to those
>conversations. To date, no industry solution has been found for the
>digital wiretap problem, according to Kenneth Raymond, a Nynex
>telephone company engineer, who is the industry co-chairman of the
>group.
>
>Oh, there's also a small, but nagging problem:  The FBI hasn't
>provided a concrete basis that such solutions are needed, Raymond
>said.  CPSR's Sobel raised these same points during the panel
>discussion.
>
>The telecommunications industry is focused on "trying to evaluate
>just what is the nature of the [digital access] problem and how we
>can best solve it in some reasonable way that is consistent with
>cost and demand," Raymond said.   One solution might be to write
>digital wiretap access into future switch specifications, he said.
>
>If and when the industry does find that solution, do you think the
>FBI will put out a press release to tell us about it? "I doubt it
>very much," said FBI agent Barry Smith with the Bureau's
>Congressional Affairs office. "It will be done quietly, with no
>media fanfare."
>
>Is it just me or are these headlights getting REALLY close?
>
>The FBI's Settle is also adamant about trap door specifications
>being written into any blue prints for the National Information
>Infrastructure. But there's a catch.  Settle calls these "security
>measures," because they'll give his office a better chance at
>"catching bad guys."  He wants all networks "to be required to
>install some kind of standard for security."  And who's writing
>those standards?  You guessed it:  The NSA with input from the FBI
>and other assorted spook agencies.
>
>Settle defends these standards saying that the "best we have going
>for us is that the criminal element hasn't yet figured out how to
>use this stuff [encryption and networks in general].  When they do,
>we'll be in trouble. We want to stay ahead of the curve."
>
>In the meantime, his division has to hustle.  The FBI currently has
>only 25 "net literate" personnel, Settle admitted. "Most of these
>were recruited 2 years ago," he said.  Most have computer science
>degrees and were systems administrators at time, he said.
>
>You think that's funny?    One of your friends is probably an FBI Net
>Snitch, working for Settle.  Don't laugh.
>
>Don't Look Now, Your Privacy Is Showing
>=======================================
>
>The law enforcement establishment doesn't think you really know
>what you expect when it comes to privacy.
>
>U.S. Attorney Walker says:  "If you ask the public, 'Is privacy
>more important than catching criminals?'  They'll tell you, 'No.'"
>
>(Write him with your own thoughts, won't you?)
>
>Because of views like Walker's, the Electronic Communications
>Privacy Act (ECPA) "needs to be broader," said Mike Godwin, legal
>services counsel, for Electronic Frontier Foundation, speaking as
>a panel member.  The ECPA protects transmitted data, but it also
>needs to protect stored data, he said.  "A person's expectation of
>privacy doesn't end when they store something on a hard disk."
>
>But Walker brushed Godwin aside saying, "It's easy to get caught up
>in the rhetoric that privacy is the end all be all."
>
>Do you have an expectation of privacy for things you store on your
>hard disk, in your own home?  Walker says that idea is up for
>debate:  "Part of this working group is to establish what is a
>reasonable expectation of privacy."
>
>That's right.    Why?  Because for people like
>Walker, those guardians of justice, "There has to be a balance
>between privacy needs and law enforcement needs to catch
>criminals," he says.
>
>Balance, yes.  Total abrogation of my rights?  Fat chance.
>
>
>Meeks out...
>
>
>
>
>
>

{% endraw %}
```

## Thread

+ Return to [February 1994](/archive/1994/02)

+ Return to<EMAIL_ADDRESS>(Reynolds Griffith)](/authors/f_griffith_at_ccsvax_sfasu_edu_reynolds_griffith_)"

+ 1994-02-01 (Tue, 1 Feb 94 07:15:28 PST) - Privacy As Roadkill -<EMAIL_ADDRESS>(Reynolds Griffith)_


text:
[![CircleCI](https://circleci.com/gh/devatherock/simple-slack.svg?style=svg)](https://circleci.com/gh/devatherock/simple-slack)
[![Version](https://img.shields.io/docker/v/devatherock/simple-slack?sort=semver)](https://hub.docker.com/r/devatherock/simple-slack/)
[![Coverage Status](https://coveralls.io/repos/github/devatherock/simple-slack/badge.svg?branch=master)](https://coveralls.io/github/devatherock/simple-slack?branch=master)
[![Quality Gate](https://sonarcloud.io/api/project_badges/measure?project=simple-slack&metric=alert_status)](https://sonarcloud.io/component_measures?id=simple-slack&metric=alert_status&view=list)
[![Docker Pulls](https://img.shields.io/docker/pulls/devatherock/simple-slack.svg)](https://hub.docker.com/r/devatherock/simple-slack/)
[![Lines of Code](https://sonarcloud.io/api/project_badges/measure?project=simple-slack&metric=ncloc)](https://sonarcloud.io/component_measures?id=simple-slack&metric=ncloc)
[![Docker Image Size](https://img.shields.io/docker/image-size/devatherock/simple-slack.svg?sort=date)](https://hub.docker.com/r/devatherock/simple-slack/)
# simple-slack
CI plugin to post messages to [Slack](https://slack.com/) or other chat clients with Slack compatible incoming webhooks like [Rocket.Chat](https://rocket.chat/)

## Config

The following parameters/secrets can be set to configure the plugin.

### Parameters
* **color** - Color in which the message block will be highlighted.
* **text** - The message content. The text uses go templating. Any environment variable available at runtime can be used within the text, after converting it to camel case. For example, to use the environment variable `DRONE_BUILD_STATUS`, the syntax will be `{{.DroneBuildStatus}}`

### Secrets

The following secret values can be set to configure the plugin.

* **SLACK_WEBHOOK** - The slack webhook to post the message to

## Usage

### Docker:
Execute from the working directory:

```
docker run --rm \
  -e SLACK_WEBHOOK=https://hooks.slack.com/services/... \
  -e PARAMETER_COLOR=#33ad7f \
  -e PARAMETER_TEXT="Success: {{.BuildLink}} ({{.BuildRef}}) by {{.BuildAuthor}}" \
  -e PARAMETER_CHANNEL="xyz" \
  -e PARAMETER_TITLE="Build completed" \
  -e BUILD_REF="refs/heads/master" \
  -e BUILD_AUTHOR=octocat \
  -e BUILD_LINK=http://github.com/octocat/hello-world \
  devatherock/simple-slack:latest
```

### Drone:

```yaml
pipeline:
  notify_slack:
    when:
      event: [ push ]
      status: [ success, failure, error ]
    image: devatherock/simple-slack:latest
    secrets: [ slack_webhook ]
    settings:
      color: "#33ad7f"
      text: |-
        {{.DroneBuildStatus}} {{.DroneBuildLink}} ({{.DroneCommitRef}}) by {{DroneCommitAuthor}}
        {{.DroneCommitMessage}}
```

### Vela:

```yaml
steps:
  - name: notify_slack
    ruleset:
      event: [ push ]
      status: [ success ]
    image: devatherock/simple-slack:latest
    secrets: [ slack_webhook ]
    parameters:
      color: "#33ad7f"
      text: |-
        Success: {{.BuildLink}} ({{.BuildRef}}) by {{.BuildAuthor}}
        {{.BuildMessage}}
```

repository: devatherock/simple-slack

gha_language: Go

repo_name: devatherock/simple-slack