text:
It provides the needed types to interact with the New Relic REST API.

It's still in progress and I haven't finished the entirety of the API, yet. I
plan to finish all GET (read) operations before any POST (create) operations,
and then PUT (update) operations, and, finally, the DELETE operations.

The API documentation can be found from [New Relic][1],
and you'll need an API key (for some operations, an Admin API key is
required).

## USAGE

This library will provide a client object and any operations can be performed
through it. Simply import this library and create a client to get started:

```go
package main

import (
  "github.com/yfronto/newrelic"
)

var api_key = "..." // Required

func main() {
  // Create the client object
  client := newrelic.NewClient(api_key)

  // Get the applciation with ID 12345
  myApp, err := client.GetApplication(12345)
  if err != nil {
    // Handle error
  }

  // Work with the object
  fmt.Println(myApp.Name)

  // Some operations accept options
  opts := &newrelic.AlertEventOptions{
    // Only events with "MyProduct" as the product name
    Filter: newRelic.AlertEventFilter{
      Product: "MyProduct",
    },
  }
  // Get a list of recent events for my product
  events, err := client.GetAlertEvents(opts)
  if err != nil {
    // Handle error
  }
  // Display each event with some information
  for _, e := range events {
    fmt.Printf("%d -- %d (%s): %s\n", e.Timestamp, e.Id, e.Priority, e.Description)
  }
}
```

## Contributing

As I work to populate all actions, bugs are bound to come up. Feel free to
send me a pull request or just file an issue. Staying up to date with an API
is hard work and I'm happy to accept contributors.

**DISCLAIMER:** *I am in no way affiliated with New Relic and this work is
merely a convenience project for myself with no guarantees. It should be
considered "as-is" with no implication of responsibility. See the included
LICENSE for more details.*

[1]: http://www.newrelic.com

repository: krinklesaurus/newrelic

repo_name: krinklesaurus/newrelic


text:
---
layout: default
---

# 1993-09-20 - Re: your mail

## Header Data

From<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: 0f67f3ae97b7e7bb70a5e7b43efa136053bca2a6e126c98ce62af350c3dc73a6

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1993-09-20 23:31:17 UTC

Raw Date: Mon, 20 Sep 93 16:31:17 PDT

## Raw message

```
{% raw  %}From<EMAIL_ADDRESS>Date: Mon, 20 Sep 93 16:31:17 PDT
To<EMAIL_ADDRESS>Subject: Re: your mail
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

What do you put in the Subject: line of an encrypted or anonymous
message?

We need something standard to prevent traffic analysis on this field.

My suggestion is always to put "Subject: Re: your mail", since so much
mail already has that, due to a feature of the popular mailer elm.

If there is no standard, one could correlate Subject: patterns with
people.

Notice this message has been sent through "fmt" (and almost through
"spell") to remove more nuances.  Next we need an
English-to-bland-English translator that smooths over individual
language features (unless you're practicing stegonagraphy, then you
want one that inserts them!)

{% endraw %}
```

## Thread

+ Return to [September 1993](/archive/1993/09)

+ Return to<EMAIL_ADDRESS>(smells huh?)](/authors/anon_at_avon_org_smells_huh_)"
+ Return to "[nobody@soda.berkeley.edu](/authors/nobody_at_soda_berkeley_edu)"

+ 1993-09-20 (Mon, 20 Sep 93 16:31:17 PDT) - Re: your mail -<EMAIL_ADDRESS>  + 1993-09-21 (Tue, 21 Sep 93 07:48:03 PDT) - [Re: Re: your mailRe: Re: your mail](/archive/1993/09/c0f9ab7f853a531b011e09f6d62838539aff50fac03e16400f1ba1a8bab8e609) -<EMAIL_ADDRESS>(smells huh?)_

license: MIT

branch_name: refs/heads/master

extension: md

gha_license_id: MIT

license_type: permissive


text:
# WinConsole

The script:

1. Notices you to install a specific font, and sets it as a console font;
2. Removes all current console settings and sets the default as that to Gee’s preference.

You should **NOT** use this script directly (you need to tweak it) unless you use Chinese in Windows console. You have to acquire `Microsoft YaHei Mono` font yourself from [here](https://github.com/Microsoft/WSL/issues/2463#issuecomment-334692823).

repository: GeeLaw/PowerShellThingies

gha_language: PowerShell

repo_name: GeeLaw/PowerShellThingies


text:
---
layout: post
title:  "Group Meeting 10/24/2021"
date:   2021-10-24
author: Chang
categories: activities
---

## Discussion on Research Topics

#### Dicong Liang: The Study on Polarization Modes of Gravitational Waves and Their Detection

Ref: Liang et al. 2017 [[Polarizations of gravitational waves in f(R) gravity](https://journals.aps.org/prd/abstract/10.1103/PhysRevD.95.104034)]

Ref2: Gong et al. 2018 [[Gravitational waves in Einstein-æther and generalized TeVeS theory after GW170817](https://journals.aps.org/prd/abstract/10.1103/PhysRevD.97.084040)]

Ref3: Liang et al. 2019 [[Frequency response of space-based interferometric gravitational-wave detectors](https://journals.aps.org/prd/abstract/10.1103/PhysRevD.99.104027)]

#### Ziming Wang:  New limits on the Lorentz/CPT symmetry through fifty gravitational-wave events

Ref: Wang et al. 2021 [[arXiv](https://arxiv.org/abs/2108.02974)]

gha_language: SCSS


text:
# MyBotler for iOS
This is a administrative applikation for cafes, that use Botler.

### Download a deployed version in the App store.
https://itunes.apple.com/dk/app/mybotler/id1155305961?mt=8

### Language:
Swift 3.0

### Deployment version:
iOS 9.0 +

## Developer
Joachim Dittman Jepsen
https://github.com/Joachimdj

repository: Joachimdj/JobResume

repo_name: Joachimdj/JobResume


text:
---
layout: post
title: Hello World Indeed
---
Welcome to this humble endeavour.Since everything must begin with a plan, I have decided to outline what I will be doing with the blog.

Posts about culture, technology, programming etc

Since I belong to a country of _argumentative Indians_, there will be occasional posts about Politics and other stuff.

Occassionally there would be series inspired by books like *Pragmatic Programmer*

I have decided to go for a formatting that is similar to the [Codeless Code](http://thecodelesscode.com/).Since I believe we are all nothing but storytellers.Let us give this ancestral form of story telling a revival.
I think thats all I can go about it now.

>The first rays of sun swept the palace and Shehrezade fell silent.


text:
# Group layers

Group a collection of layers together and toggle their visibility as a group.

![Image of group layers](group-layers.png)

## Use case

Group layers communicate to the user that layers are related and can be managed together.

In a land development project, you might group layers according to the phase of development.

## How to use the sample

Display the layers in the map in a table of contents by clicking the map icon at the top right. Toggle the checkbox next to a layer's name to change its visibility. Turning a group layer's visibility off will override the visibility of its child layers.

## How it works

1. Add the `GroupLayer` and additional `Layer`s as operational layers in the `SceneView`.
2. To build the table of contents:
  * Add each layer to the table of contents.
  * For each `Layer` in the `SceneView`, if `canShowInLegend()` returns true, add it to the table of contents.
3. To toggle the visibility of the group, simply change the group layer's visibility property.

## Relevant API

* GroupLayer

## Additional information

The full extent of a group layer may change when child layers are added/removed. Group layers do not have a spatial reference, but the full extent will have the spatial reference of the first child layer.

Group layers can be saved to web scenes. In web maps, group layers will be ignored.

## Tags

group layer, layers

repository: XiehangX/arcgis-runtime-samples-android

gha_language: Java

repo_name: XiehangX/arcgis-runtime-samples-android


text:
# aseprite-renderer

This is a module to directly read the files of [aseprite](https://www.aseprite.org/) without having to manually export them to a more common format like PNG.

It's very feature-incomplete, and only has features I've needed so far.
You should probably not trust that it will faithfully render any given
aseprite file without verifying for yourself.

## Testing

```bash
$ mocha .
```

The tests will attempt to parse a number of aseprite files, output them as PNGs,
then compare the output to output generated by aseprite itself.
To add a new test case, add the `.ase` file to `testdata/`, then run
`mocha . --regen <path to your aseprite binary>` to generate your reference PNG.

repository: justinj/aseprite-renderer

branch_name: refs/heads/main

repo_name: justinj/aseprite-renderer


text:
Livewire properties are able to modified freely on both the frontend and backend using utilities like `wire:model`. If you want to prevent a property—like a model ID—from being modified on the frontend, you can use Livewire's `#[Locked]` attribute.

## Basic usage

Below is a `ShowPost` component that stores a post model's ID as a public property named `$id`. To keep this property from being modified by a curious or malicious user, you can add the `#[Locked]` attribute to the property:

```php
use Livewire\Attributes\Locked;
use Livewire\Component;

class ShowPost extends Component
{
	#[Locked] // [tl! highlight]
    public $id;

    public function mount($postId)
    {
        $this->id = $postId;
    }

	// ...
}
```

By adding the `#[Locked]` attribute, you are ensured that the `$id` property will never be tampered with.

> [!tip] Model properties are secure by default
> If you store an Eloquent model in public property instead of just the model's ID, Livewire will ensure the ID isn't tampered with without you needing to explicitly add the `#[Locked]` attribute to the property. For most cases, this is a better approach than using `#[Locked]`:
> ```php
> class ShowPost extends Component
> {
>    public Post $post; // [tl! highlight]
>
>    public function mount($postId)
>    {
>        $this->post = Post::find($postId);
>    }
>
>	// ...
>}
> ```

### Why not use protected properties?

You might ask yourself: why not just protected properties for sensitive data?

Remember, Livewire only persists public properties between network requests. For static, hard-coded data, protected properties are suitable. However, for data that is stored at runtime, you must use a public property to ensure that the data is persisted properly.

### Can't Livewire do this automatically?

In a perfect world, Livewire would lock properties by default, and only allow modifications when `wire:model` is used on that property.

Unfortunately, that would require Livewire to parse all of your Blade templates to understand if a property is modified by `wire:model` or a similar API.

Not only would that add technical and performance overhead, it would be impossible to detect if a property is mutated by something like Alpine or any other custom JavaScript.

Therefore, Livewire will continue to make public properties freely mutable by default and give developers the tools to lock them as needed.

repository: mokhosh/livewire

repo_name: mokhosh/livewire


text:
---
layout: default
---

# 1996-04-13 - Re: [NOISE] Why there are so many cluless people

## Header Data

From<EMAIL_ADDRESS>(Timothy C. May)

To<EMAIL_ADDRESS>Message Hash: 293e8b1aa45430baa4adb09db8864b0a0331aa17e5567cc61659fec79a29e55c

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1996-04-13 07:46:09 UTC

Raw Date: Sat, 13 Apr 1996 15:46:09 +0800

## Raw message

```
{% raw  %}From<EMAIL_ADDRESS>(Timothy C. May)
Date: Sat, 13 Apr 1996 15:46:09 +0800
To<EMAIL_ADDRESS>Subject: Re: [NOISE] Why there are so many cluless people
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

At 10:11 PM 4/12/96, Andrew Loewenstern wrote:

>I heard that Internet Privacy Guaranteed is coming out with their own set of
>cassette tapes...  ;-)
>
>"Become a cryptanalyst in 21 days, while you sleep, or your money back!"

This is old news. "Subliminal channels" have been around  in crypto for a
long time.

--Klaus! von Future Prime

{% endraw %}
```

## Thread

+ Return to [April 1996](/archive/1996/04)

+ Return to<EMAIL_ADDRESS>(Timothy C. May)](/authors/tcmay_at_got_net_timothy_c_may_)"

+ 1996-04-13 (Sat, 13 Apr 1996 15:46:09 +0800) - Re: [NOISE] Why there are so many cluless people -<EMAIL_ADDRESS>(Timothy C. May)_


text:
autofill-directive
==================

AngularJS directive that fixes the issue where browsers autofill inputs and they aren't reflective in the model upon submit.

#### Install with Bower:

```
bower install autofill-directive
```

#### Include the directive in your Angular module:

```
var myApp = angular.module('myApp', ['autofill-directive']);
```

## Usage

Use the `autofill-submit` directive on the form that you are submitting and provide the angular expression you want executed. Then place the `autofill` directive on any inputs that may be autofilled by the browser. Now the `model` will be updated to reflect what the browser has autofilled into the input BEFORE the submit expression is executed.

```html
<form autofill-submit="login()">
	<input autofill ng-model="username" placeholder="Username" type="text" />
	<input autofill ng-model="password" placeholder="Password" type="password" />
	<input type="submit" value="Login" />
</form>
```

repository: chesleybrown/autofill-directive

repo_name: chesleybrown/autofill-directive


text:
# Learn Paxos

learn-paxos is a Go program for learning the basics of the Paxos algorithm. More
specifically, it is for learning an algorithm variously referred to as "Classic
Paxos" or "Single-Decree Paxos."

It my opinion that Paxos is much simpler to learn than is commonly believed.
Just  as the central concept of Bubble Sort can be described by the idea of
bubbling smaller items to the front of a list, the idea of Classic Paxos is
captured by the following conversation:

> Alice: Where would you two like to go to lunch?
>
> Bob and Carlos: I don't know, where do you want to go?
>
> Alice: Let's get some tacos!
>
> Bob and Carlos: OK, let's get some tacos!

There really is not much more to the intuition behind Classic Paxos than an
idea of why the above conversation works. OK, sure, there are some identifiers,
a quorum concept, the fact that messages can be dropped or rearranged, and that
participants can become unreachable. But there are details to bubble sort too,
and such details enrich our understanding of the algorithm rather than stand in
the way of our intuition.

The code in this repository closely follows the algorithms in chapter 2 of Dr.
Heidi Howard's Ph.D. dissertation [1]. My recommended study plan for learning
Classic Paxos would be as follows:

1. Read sections 2.2 and 2.3 of Dr. Howard's dissertation.
2. Implement algorithms 3 and 4, the proposer and acceptor algorithms, in
   a programming language of your choice. You're welcome to clone this
   repository if you'd like.
3. Read sections 2.4-2.7 of Dr. Howard's dissertation, to understand
   the safety and progress properties of Classic Paxos.

## Terminology

When I try to understand code that corresponds to an academic work, I am
frequently confused by differences in terminology between the code and the
paper. To make understanding the code in this repository easier, it adheres to
the following naming conventions:

Name in [1]     | Name in this code | Meaning
----------------| ----------------- | ---------------------------------
e               | epoch             | epoch (component of all messages)
v               | value             | proposal value
na   | nAcceptors        | number of acceptors
QP   | promisedAcceptors | acceptors that have promised
QA   | acceptedAcceptors | acceptors that have accepted
f               | lastAcceptedEpoch | last accepted epoch (component of prepare message)
v               | lastAcceptedValue | last accepted value (component of prepare message)
𝛾               | candidateValue    | value that proposer will propose if it is sure no other value is chosen
epro | promisedEpoch     | last promised epoch
eacc | acceptedEpoch     | last accepted epoch
vacc | acceptedValue     | last accepted value

## Nil values

In the presentation in [1], epochs and values may be nil. In the code in this
repository, a nil epoch is any epoch in which the *big.Int field is nil (any
epoch e for which e.nil() returns true), and the nil value is the empty string.

## Persistence

If participants in Paxos may both crash and recover, then the algorithm requires
that the participants remember some of their variables across restarts, i.e.,
they must store those variables on a durable storage medium, such as a disk. (If
participants may crash but not recover, the durability requirements disappear,
but I digress.) When first learning Paxos, the best way to understand
persistence requirements is to pay attention to what variables must be
persisted. I believe that any more detailed consideration of persistence is a
distraction when first learning Paxos, and that reason, I have omitted any
notion of persistence from this repository.

## References

[1] Heidi Howard. 2019. _Distributed Consensus Revised_. University of Cambridge
Computer Laboratory Technical Report UCAM-CL-TR-935. University of Cambridge,
Cambridge, England. Retrieved from https://www.cl.cam.ac.uk/techreports/.


text:
Move2Kube
---------
Congratulations! Move2Kube has generated the necessary build artfiacts for moving all your application components to Kubernetes. Using the artifacts in this directory you can deploy your application in a kubernetes cluster.

Prerequisites
-------------
* Docker
* Helm
* Kubectl
* Source-To-Image (S2I) https://github.com/openshift/source-to-image

Next Steps
----------
{{if .NewImages -}}
* Copy the source directory into the containers folder for packaging as containers using "copysource.sh <SRC_DIR>"
* Build your images using "buildimages.sh"
* Push images to registry "pushimages.sh <REGISTRY_URL> <REGISTRY_NAMESPACE>"
{{end -}}
{{- if .Helm -}}* Your helm chart is at {{ .Project }}, you can install it using "helminstall.sh" or you can use the operator.{{- else -}}
* Use "deploy.sh" to deploy your artifacts into a kubernetes cluster.
{{- end}}
{{if .AddCopySourcesWarning }}
IMPORTANT!!: If you used the UI for translation then "copysources.sh" may copy to the wrong folder.
This is a limitation of the beta version. It should be fixed in future versions of move2kube-ui.
In the meantime you can either:
- copy the sources to the appropriate folders inside "./containers/" manually. "./containers/" has
  the same folder structure as the sources folder so simply copy the appropriate source files/folders
  to the corresponding folders inside "./containers/".
- move the sources into a directory with the same name and then try copysources with that.
  Example: if sources is a folder called "foo" you might try moving it into "foo/foo/foo" and then
  doing "./copysources.sh path/to/foo/". This will require you to read "copysource.sh" and have some knowledge
  of how "cp -r" works in order to get it right.
{{ end }}


text:
    Dockerized Windscribe SOCKS5 Server

    Containerizes a SOCKS5 proxy server with traffic tunneled through Windscribe's VPN service

## Table of Contents
- [Motivations](#motivations)
- [Pro Et Contra](#pro-et-contra)
  - [Advantages](#advantages)
  - [Limitations](#limitations)
- [Deployment](#deployment)
  - [Image Source](#image-source)
  - [Deploying Container](#deploying-container)
    - [Docker Compose](#docker-compose)
    - [Docker CLI](#docker-cli)
  - [Configuration](#configuration)
- [Disclaimer](#disclaimer)

## Motivations
[Windscribe](https://windscribe.com/) is a yet another VPN service, offering varying subscriptions plans (free, pro, "build a plan", etc). Typically, [Windscribe software](https://windscribe.com/download) must be installed on host devices to tunnel traffic through their VPN servers. However, there are [other protocols](https://windscribe.com/features/config-generators) (e.g. OpenVPN, IKEv2, SOCKS5, etc) supported for tunneling *without* their proprietary software. Unfortunately, these protocols are only available to users on their "Pro" subscription plan (i.e. excluding free and "Build A Plan" subscription plans).

I had submitted a feature request for SOCKS5 support for the "Build A Plan" option from their support, but have received a generic response indicating there was no particular interest in adding such support for non-"Pro" subscription plans. Ergo, Windscribe software must be installed on a host device to tunnel traffic, presenting two corollaries:
- a host device must be eligible for installing and running Windscribe VPN software
- _all_ system traffic will be tunneled through Windscribe servers

This project was created to address a fringe use-case and circumvent the aforementioned corollaries by containerizing Windscribe software within [Docker](https://www.docker.com/), enabling tunneling through as a SOCKS5 proxy server.

## Pro Et Contra
### Advantages
There are a few useful advantages of using this containerized application:
- Paid subscriptions are not required to use the SOCKS5 protocol to tunnel traffic through Windscribe.
- A host device does not need to install Windscribe system software and can still tunnel traffic through their VPN servers.
- Networking tools (e.g. [Proxifier](https://www.proxifier.com/)) can enable fine-grained control by handling per-process traffic tunneling, rather than system wide traffic tunneling.

### Limitations
However, there limitations to this project's usefulness relating significantly to security:
- Traffic to the SOCKS5 server is _not_ encrypted and may be interceptable by a third party; however, traffic forwarded to Windscribe is encrypted.
- Without authentication, the SOCKS5 server should _only_ be used in a tightly controlled network. Exposing the SOCKS5 server publicly allows any actor to tunnel traffic that is linked back to the specified Windscribe account. As of version `0.3.0`, proxy server authentication can be configured through environment variables.
- [Windscribe-CLI](https://windscribe.com/guides/linux) requires `iptables` support, requiring the `NET_ADMIN` cap permission to execute inside of a Docker container. As a consequence, a compromised container may be able to leverage all the capabilities of `CAP_NET_ADMIN`, as defined in the [Linux manuals](http://man7.org/linux/man-pages/man7/capabilities.7.html). While it is unlikely the software involved would be compromised, there is a non-zero possibility that a compromised container may be able to manipulate the host's iptables for malicious purposes.

## Deployment
This project must be built using a container image building tool and run using container runtime (e.g. Docker, Podman, etc). [Docker](https://www.docker.com/) instructions are included in the following sections.

### Image Source
Pre-built images can be pulled from any of the following registries:
- [Docker Hub](https://hub.docker.com/r/concisions/windscribe-socks-server): `concisions/windscribe-socks-server:latest`
- [GitHub Packages](https://github.com/concision/docker-windscribe-socks-server/packages): `docker.pkg.github.com/concision/docker-windscribe-socks-server/windscribe-socks-server:latest`
> Note: The only prebuilt images architectures available are `linux/amd64` and `linux/arm/v7`. At the time of writing this documentation, Windscribe distributions are not available for other architectures.

Alternatively, the project can be built from the repository's sources by cloning the repository and running a container image build tool.
```bash
# clone the repository
git clone https://github.com/concision/docker-windscribe-socks-server.git
# change current working directory
cd docker-windscribe-socks-server
# build Docker image
docker build -t concisions/windscribe-socks-server:latest .
```
> Note: Ensure the current working directory is inside of the cloned Git repository prior to executing the command (e.g. `cd docker-windscribe-socks-server`).

### Deploying Container
#### Docker Compose
To deploy with [Docker Compose](https://docs.docker.com/compose/), use the commented configuration file available in this repository [here](https://github.com/concision/docker-windscribe-socks-server/blob/master/docker-compose.yml). Environment variables may be sourced with an `.env` file or explicitly defined in the configuration file.

The container can be deployed with the following command:
```bash
docker-compose up
```

> Note: An `.env` file containing all environment variable configuration can be passed as a [Docker secret](https://docs.docker.com/engine/swarm/secrets/#use-secrets-in-compose) file using the key `windscribe_server`. Uncomment the relevant section in the [`docker-compose.yml`](https://github.com/concision/docker-windscribe-socks-server/blob/master/docker-compose.yml) file template. Configured Docker secrets take precedence over environment variables.

#### Docker CLI
To deploy with [Docker](https://www.docker.com/), use the example run script available in this repository [here](https://github.com/concision/docker-windscribe-socks-server/blob/master/deploy-container.sh). It can be configured in the script itself or use an `.env` file.

The container can be deployed with the following command:
```bash
./deploy-container.sh
```
> Note: If specifying multiple SOCKS5 users, specify the relevant environment variables in an `.env` file or add `--env SOCKS_USERNAME_xyz` and `--env SOCKS_PASSWORD_xyz` flag (where "xyz" is a wildcard) to the script.

### Configuration
There are several variables that can be configured for this image:
- **Windscribe**:
  - `WINDSCRIBE_DNS` (optional): Whitespace delimited list of DNS servers to use (default: `<IP_ADDRESS>`). Setting a DNS server with Docker flags is not sufficient enough, as it utilizes an embedded local DNS server. Windscribe tunnels all DNS requests to prevent DNS leakage.
  - `WINDSCRIBE_USERNAME`: Windscribe account username.
  - `WINDSCRIBE_PASSWORD`: Windscribe account password.
  - `WINDSCRIBE_LOCATION` (optional): A preferred Windscribe location to automatically connect to.
- **SOCKS5 Server**:
  > Note: By default, there is no authentication enabled. Setting any of the environment variables `SOCKS_USERNAME` or `SOCKS_USERNAME_xyz` automatically enables authentication. Without authentication, the SOCKS5 server should _only_ be used in a tightly controlled network.
  - `SOCKS_USERNAME` (optional): Enables SOCKS5 authentication and creates a new user. Must be alphanumeric (with `_`s).
  - `SOCKS_PASSWORD` (optional): Enables SOCKS5 authentication and sets the password for the associated `$SOCKS_USERNAME` user.
  Additional users can be defined by namespacing (e.g. suffixing "_1") additional environment variables under pairs of `SOCKS_USERNAME` and `SOCKS_PASSWORD`:
  - `SOCKS_USERNAME_xyz` (optional): Enables SOCKS5 authentication and creates a new user. Must be alphanumeric (with `_`s).
  - `SOCKS_PASSWORD_xyz` (optional): Enables SOCKS5 authentication and sets the password for the associated `SOCKS_USERNAME_xyz` user.

## Disclaimer
This project is a prototype that has been hacked together and has its own set of issues and drawbacks compared to running Windscribe system software. Your mileage may vary. If you are experiencing an issue you believe is not intended, a GitHub issue can be filed [here](https://github.com/concision/docker-windscribe-socks-server/issues/new); however, not all issues may be solvable due to the hacky and unpredictable nature of this project and its software dependencies.


text:
# A simple Camel protocol bridge
An simple example of a production quality protocol bridge using Apache Camel

## Supported protocols
-  Websphere MQ
-  File

## Add or remove a protocol

Just add or remove a camel component dependency in build.gradle
Look at how WmqConfiguration together with the application.properties are done if you need to do some Spring bean configuration,

### Add rabbitmq
`compile "org.apache.camel:camel-rabbitmq:$camelVersion"`

repository: Eventfully/camel-protocol-bridge

repo_name: Eventfully/camel-protocol-bridge


text:
Electron Forge
--------------
[![Linux/macOS Build Status](https://travis-ci.org/electron-userland/electron-forge.svg?branch=master)](https://travis-ci.org/electron-userland/electron-forge)
[![Windows Build status](https://ci.appveyor.com/api/projects/status/79ae80nek1eucyy3?svg=true)](https://ci.appveyor.com/project/electron-userland/electron-forge)
[![Commitizen friendly](https://img.shields.io/badge/commitizen-friendly-brightgreen.svg)](http://commitizen.github.io/cz-cli/)
[![npm version](https://badge.fury.io/js/electron-forge.svg)](https://www.npmjs.com/package/electron-forge)
[![npm](https://img.shields.io/npm/dt/electron-forge.svg?maxAge=2592000)](https://www.npmjs.com/package/electron-forge)
[![license](https://img.shields.io/github/license/electron-userland/electron-forge.svg)](https://github.com/electron-userland/electron-forge/blob/master/LICENSE)
![status](https://img.shields.io/badge/Status-%20Ready%20for%20Awesome-red.svg)

A complete tool for building modern Electron applications.

Electron Forge unifies the existing (and well maintained) build tools for
Electron development into a simple, easy to use package so that anyone can
jump right in to Electron development.

# Getting Started

**Note**: Electron Forge requires Node 6 or above, plus git installed.

```bash
npm install -g electron-forge
electron-forge init my-new-app
cd my-new-app
electron-forge start
```

# Project Goals

1. Starting with Electron should be as simple as a single command.
2. Developers shouldn't have to worry about `babel`, `browserify`, `webpack`,
etc.  Everything should "just work" for them out of the box.
3. Everything from creating the project to packaging the project for release
should be handled by one dependency in a standard way while still offering users
maximum choice and freedom.

With these goals in mind, under the hood this project uses
[`electron-compile`](https://github.com/electron/electron-compile): a tool
that lets you use modern and futuristic languages inside Electron without
worrying about transpiling or build tooling.

# Usage

## Starting a new Project

```bash
npm install -g electron-forge
electron-forge init my-new-project
```

This command will generate a brand new project folder and install all your NPM
dependencies so you will be all set to go.  By default we will also install the
`airbnb` linting modules.  If you want to follow the `standard` linting rules
instead, use the `--lintstyle=standard` argument.

## Importing an existing Project

```bash
electron-forge import existing-project-directory
```

Given an existing Electron project, this command will attempt to interactively
navigate through the process of importing it to the Electron Forge format, so
the commands listed below can be used. This includes being prompted to remove
existing Electron build tools in favor of Electron Forge equivalents.

## Launching your Project

```bash
electron-forge start
```

Any arguments after "start" will be passed through to your application when
it's launched.

## Packaging your Project

```bash
electron-forge package
```

Yes, it really is that simple.  If you want to specify platform / arch, use the
`--platform=<platform>` and `--arch=<arch>` arguments.

## Generating a distributable for your Project

```bash
electron-forge make
```

This will generate platform specific distributables (installers, distribution
packages, etc.) for you. Note that you can only generate distributables for your
current platform.

## Linting your Project

```bash
electron-forge lint
```

## Publishing your Project

```bash
electron-forge publish
```

This will `make` your project and publish any generated artifacts.  By default it will publish to GitHub but you can change the publish target with `--target=YourTarget`.

# Config

Once you have generated a project, your `package.json` file will have some
default `forge` configuration.  Below is the reference structure for this
config object:

```javascript
{
  "make_targets": {
    "win32": ["squirrel"], // An array of win32 make targets
    "darwin": ["zip", "dmg"], // An array of darwin make targets
    "linux": ["deb", "rpm", "flatpak"] // An array of linux make targets
  },
  "electronPackagerConfig": {},
  "electronWinstallerConfig": {},
  "electronInstallerDMG": {},
  "electronInstallerFlatpak": {},
  "electronInstallerDebian": {},
  "electronInstallerRedhat": {}
}
```

## Possible `make` targets

| Target Name | Available Platforms | Description | Configurable Options | Default? | Requirements |
|-------------|---------------------|-------------|----------------------|----------|--------------|
| `zip`       | All                 | Zips your packaged application | None | Yes | `zip` on Darwin/Linux |
| `squirrel`  | Windows             | Generates an installer and `.nupkg` files for Squirrel.Windows | [`electronWinstallerConfig`](https://github.com/electron/windows-installer#usage) | Yes |  |
| `appx`      | Windows             | Generates a Windows Store package | [`windowsStoreConfig`](https://github.com/felixrieseberg/electron-windows-store#programmatic-usage) | No |  |
| `dmg`       | Darwin              | Generates a DMG file | [`electronInstallerDMG`](https://github.com/mongodb-js/electron-installer-dmg#api) | No |  |
| `deb`       | Linux               | Generates a Debian package | [`electronInstallerDebian`](https://github.com/unindented/electron-installer-debian#options) | Yes | [`fakeroot` and `dpkg`](https://github.com/unindented/electron-installer-debian#requirements) |
| `rpm`       | Linux               | Generates an RPM package | [`electronInstallerRedhat`](https://github.com/unindented/electron-installer-redhat#options) | Yes | [`rpm`](https://github.com/unindented/electron-installer-redhatn#requirements) |
| `flatpak`   | Linux               | Generates a [Flatpak](http://flatpak.org/) file | [`electronInstallerFlatpak`](https://github.com/endlessm/electron-installer-flatpak#options) | No | [`flatpak-builder`](https://github.com/endlessm/electron-installer-flatpak#requirements) |

## Configuring `package`

You can set `electronPackagerConfig` with **any** of the options from
[Electron Packager](https://github.com/electron-userland/electron-packager/blob/master/docs/api.md).

**NOTE:** You can also set your `forge` config property of your package.json to point to a JS file that exports the config object:

```js
{
  ...
  "config": {
    "forge": "./forge.config.js"
  }
  ...
}
```

**NOTE:** If you use the JSON object then the `afterCopy` and `afterExtract` options are mapped to `require`
calls internally, so provide a path to a file that exports your hooks and they will still run.  If you use
the JS file method mentioned above then you can use functions normally.

## Possible `publish` targets

| Target Name | Description | Required Config |
|-------------|-------------|-----------------|
| github      | Makes a new release for the current version (if required) and uploads the make artifacts as release assets | `process.env.GITHUB_TOKEN` - A personal access token with access to your releases
`forge.github_repository.owner` - The owner of the GitHub repository
`forge.github_repository.name` - The name of the GitHub repository
`forge.github_repository.draft` - Create the release as a draft, defaults to `true`
`forge.github_repository.prerelease` - Identify the release as a prerelease, defaults to `false` |

## Custom `make` and `publish` targets

You can make your own custom targets for the `make` and `publish` targets.  If you publish them as `electron-forge-publisher-{name}` or `electron-forge-maker-{name}` you can then just specify `{name}` as your make / publish target.  The API for each is documented below.

### API for `make` targets

You must export a Function that returns a Promise.  Your function will be called with the following parameters.

* `appDir` - The directory containing the packaged application
* `appName` - The productName of the application
* `targetArch` - The target architecture of the make command
* `forgeConfig` - An object representing the users forgeConfig
* `packageJSON` - An object representing the users package.json file

Your promise must resolve with an array of the artifacts you generated.

### API for `publish` targets

You must export a Function that returns a Promise.  Your function will be called with the following parameters.

* artifactPaths - An array of absolute paths to artifacts to publish
* packageJSON - An object representing the users package.json file
* forgeConfig - An object representing the users forgeConfig
* authToken - The value of `--auth-token`
* tag - The value of `--tag`

You should use `ora` to indicate your publish progress.

repository: felixrieseberg/electron-forge

repo_name: felixrieseberg/electron-forge


text:
# lita-chilean-bip

 [![Build Status](https://travis-ci.org/milo-ft/lita-chilean-bip.png)](https://travis-ci.org/milo-ft/lita-chilean-bip)
 [![Code Climate](https://codeclimate.com/github/milo-ft/lita-chilean-bip.png)](https://codeclimate.com/github/milo-ft/lita-chilean-bip)
 [![Coverage Status](https://coveralls.io/repos/milo-ft/lita-chilean-bip/badge.png)](https://coveralls.io/r/milo-ft/lita-chilean-bip)

**lita-chilean-bip** is a [Lita](https://github.com/jimmycuadra/lita) handler for checking the BIP card balance.

## Installation

Add **lita-chilean-bip** to your Lita instance's Gemfile:

``` ruby
gem "lita-chilean-bip"
```

## Usage

To check your balance:
```
You: Lita, bip 12345678
Lita: ..and your balance is: $10.000 (until 22/03/2014)
```

Also you can store your number for future requests:

```
You: Lita, my bip is 12345678
Lita: Yay! I'll remember it for later.
```

and at any time...

```
You: Lita, bip
Lita: ..and your balance is: $10.000 (until 22/03/2014)
```

Requests are case-insensitive

## License

[MIT](http://opensource.org/licenses/MIT)

repository: milo-ft/lita-chilean-bip

repo_name: milo-ft/lita-chilean-bip


text:
[日本語](./README.ja.md)

*This repository has been archived.*
*I recommend [cargo-simple-bundler](https://github.com/kuretchi/cargo-simple-bundler).*

# cargo-cherry-pick-and-bundle

Packs only necessary modules of the crate into a single file semi-automatically.
Intended to use for online judges which accept only single file submissions.

## Install

```sh
cargo install --git https://github.com/kuretchi/cargo-cherry-pick-and-bundle
```

## Usage

In a package root directory:

```sh
cargo cherry-pick-and-bundle >output.rs
```

The command reads and parses source files recursively from the root module file,
and each time it encounters `mod` or `use`, it will ask you whether it is necessary or not.
Finally, the command will create a single inline module block that contains
only necessary parts, perform the following processing, and then print it to stdout.

* Removing modules with the `#[cfg(test)]` attribute
* Removing documentation comments
* Replacing the keyword `crate` in paths with `super`s

## Related tools

* [shino16/cargo-auto-bundle](https://github.com/shino16/cargo-auto-bundle)
* [qryxip/cargo-equip](https://github.com/qryxip/cargo-equip)
* [hatoo/cargo-snippet](https://github.com/hatoo/cargo-snippet)

## License

[MIT License](./LICENSE-MIT) or [Apache License 2.0](./LICENSE-APACHE)

repository: kuretchi/cargo-cherry-pick-and-bundle

repo_name: kuretchi/cargo-cherry-pick-and-bundle


text:
# Coronavirus Dashboard: API Micro-services.

## Data API

## Lookup API

### Credits
This service is developed and maintained by [Public Health England](https://www.gov.uk/government/organisations/public-health-england).

---

Copyright (c) 2020 Public Health England


text:
---
site: freiburg
tags: [tools]
title: UseGalaxy.eu Tool Updates for 2022-01-29
supporters:
- denbi
- elixir
---

On 2022-01-29, the tools on UseGalaxy.eu were updated by our automated tool update and installation process in [Jenkins Build #308](https://build.galaxyproject.eu/job/usegalaxy-eu/job/install-tools/#308/)

## Metagenomic Analysis

- metabat2 was updated to [76bc4efa1aeb](https://toolshed.g2.bx.psu.edu/view/iuc/metabat2/76bc4efa1aeb)

## Annotation

- interproscan was updated to [c762a1cd357e](https://toolshed.g2.bx.psu.edu/view/bgruening/interproscan/c762a1cd357e)

## Variant Calling

- pharmcat was updated to [d67642a21a1d](https://toolshed.g2.bx.psu.edu/view/bgruening/pharmcat/d67642a21a1d)
- bcftools_annotate was updated to [403553ae19f6](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_annotate/403553ae19f6)
- bcftools_call was updated to [072f606e2e69](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_call/072f606e2e69)
- bcftools_call was updated to [5801eff9ac7e](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_call/5801eff9ac7e)
- bcftools_concat was updated to [874cc12ae316](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_concat/874cc12ae316)
- bcftools_concat was updated to [d40d4bf05718](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_concat/d40d4bf05718)
- bcftools_consensus was updated to [d6dc477167f8](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_consensus/d6dc477167f8)
- bcftools_convert_from_vcf was updated to [b8e9da766b0f](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_convert_from_vcf/b8e9da766b0f)
- bcftools_convert_to_vcf was updated to [fec517907949](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_convert_to_vcf/fec517907949)
- bcftools_csq was updated to [f10f5b4e7854](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_csq/f10f5b4e7854)
- bcftools_csq was updated to [fdd127bd4a32](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_csq/fdd127bd4a32)
- bcftools_filter was updated to [6ca7c55a27e8](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_filter/6ca7c55a27e8)
- bcftools_gtcheck was updated to [672b6c02fbc7](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_gtcheck/672b6c02fbc7)
- bcftools_isec was updated to [02f349bdbf96](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_isec/02f349bdbf96)
- bcftools_merge was updated to [9473302f4588](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_merge/9473302f4588)
- bcftools_merge was updated to [e03f2f3ac3a9](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_merge/e03f2f3ac3a9)
- bcftools_mpileup was updated to [0dbff46d5a1b](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_mpileup/0dbff46d5a1b)
- bcftools_norm was updated to [a62e934346f5](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_norm/a62e934346f5)
- bcftools_norm was updated to [c077f71d351f](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_norm/c077f71d351f)
- bcftools_plugin_color_chrs was updated to [71dfde92fd57](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_plugin_color_chrs/71dfde92fd57)
- bcftools_plugin_color_chrs was updated to [c39113e2ae34](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_plugin_color_chrs/c39113e2ae34)
- bcftools_plugin_frameshifts was updated to [48ac4d611e92](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_plugin_frameshifts/48ac4d611e92)
- bcftools_plugin_frameshifts was updated to [eb22990a2be9](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_plugin_frameshifts/eb22990a2be9)
- bcftools_query was updated to [c9c5718edc19](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_query/c9c5718edc19)
- bcftools_reheader was updated to [9ef52d95114b](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_reheader/9ef52d95114b)
- bcftools_roh was updated to [b76adb2f1c51](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_roh/b76adb2f1c51)
- bcftools_view was updated to [98d5499ead46](https://toolshed.g2.bx.psu.edu/view/iuc/bcftools_view/98d5499ead46)
- vardict_java was updated to [e0734e88a104](https://toolshed.g2.bx.psu.edu/view/iuc/vardict_java/e0734e88a104)

## Get Data

- ncbi_datasets was updated to [1a7773882d2c](https://toolshed.g2.bx.psu.edu/view/iuc/ncbi_datasets/1a7773882d2c)

## Assembly

- abyss was updated to [8f1b150a2487](https://toolshed.g2.bx.psu.edu/view/iuc/abyss/8f1b150a2487)
- rnaspades was updated to [ef69617ecb42](https://toolshed.g2.bx.psu.edu/view/iuc/rnaspades/ef69617ecb42)
- spades_biosyntheticspades was updated to [1bb12736175c](https://toolshed.g2.bx.psu.edu/view/iuc/spades_biosyntheticspades/1bb12736175c)
- spades_biosyntheticspades was updated to [42a39792aaae](https://toolshed.g2.bx.psu.edu/view/iuc/spades_biosyntheticspades/42a39792aaae)
- spades_coronaspades was updated to [7004279ff8b7](https://toolshed.g2.bx.psu.edu/view/iuc/spades_coronaspades/7004279ff8b7)
- spades_coronaspades was updated to [808b3a0a6716](https://toolshed.g2.bx.psu.edu/view/iuc/spades_coronaspades/808b3a0a6716)
- spades_metaplasmidspades was updated to [32ab23671cc1](https://toolshed.g2.bx.psu.edu/view/iuc/spades_metaplasmidspades/32ab23671cc1)
- spades_metaplasmidspades was updated to [8d4b90bf9caf](https://toolshed.g2.bx.psu.edu/view/iuc/spades_metaplasmidspades/8d4b90bf9caf)
- spades_metaviralspades was updated to [9346dcffaafc](https://toolshed.g2.bx.psu.edu/view/iuc/spades_metaviralspades/9346dcffaafc)
- spades_metaviralspades was updated to [f1532cb33c75](https://toolshed.g2.bx.psu.edu/view/iuc/spades_metaviralspades/f1532cb33c75)
- spades_plasmidspades was updated to [e41dcb0e913b](https://toolshed.g2.bx.psu.edu/view/iuc/spades_plasmidspades/e41dcb0e913b)
- spades_plasmidspades was updated to [eabeb1a74dac](https://toolshed.g2.bx.psu.edu/view/iuc/spades_plasmidspades/eabeb1a74dac)
- spades_rnaviralspades was updated to [249f6a28c751](https://toolshed.g2.bx.psu.edu/view/iuc/spades_rnaviralspades/249f6a28c751)
- spades_rnaviralspades was updated to [5df83f4bad67](https://toolshed.g2.bx.psu.edu/view/iuc/spades_rnaviralspades/5df83f4bad67)
- metaspades was updated to [a9b8c9e204ee](https://toolshed.g2.bx.psu.edu/view/nml/metaspades/a9b8c9e204ee)
- metaspades was updated to [f338e9942b27](https://toolshed.g2.bx.psu.edu/view/nml/metaspades/f338e9942b27)
- spades was updated to [74f20c988994](https://toolshed.g2.bx.psu.edu/view/nml/spades/74f20c988994)
- spades was updated to [d2d1df21dfb9](https://toolshed.g2.bx.psu.edu/view/nml/spades/d2d1df21dfb9)

## Phylogenetics

- nextalign was updated to [6f6a2cb188cf](https://toolshed.g2.bx.psu.edu/view/iuc/nextalign/6f6a2cb188cf)
- nextclade was updated to [64be7ff9b97b](https://toolshed.g2.bx.psu.edu/view/iuc/nextclade/64be7ff9b97b)

## Virology

- read_it_and_keep was updated to [554aa2a63f04](https://toolshed.g2.bx.psu.edu/view/iuc/read_it_and_keep/554aa2a63f04)

## ChemicalToolBox

- acpype_amber2gromacs was updated to [5b4ae74b7f0b](https://toolshed.g2.bx.psu.edu/view/chemteam/acpype_amber2gromacs/5b4ae74b7f0b)
- ambertools_acpype was updated to [095ad4d096d1](https://toolshed.g2.bx.psu.edu/view/chemteam/ambertools_acpype/095ad4d096d1)
- ambertools_antechamber was updated to [4fff93efc0f9](https://toolshed.g2.bx.psu.edu/view/chemteam/ambertools_antechamber/4fff93efc0f9)
- ambertools_antechamber was updated to [8a839e6a1e3e](https://toolshed.g2.bx.psu.edu/view/chemteam/ambertools_antechamber/8a839e6a1e3e)
- ambertools_parmchk2 was updated to [7c9bfca84241](https://toolshed.g2.bx.psu.edu/view/chemteam/ambertools_parmchk2/7c9bfca84241)
- ambertools_parmchk2 was updated to [ecc43bf27a49](https://toolshed.g2.bx.psu.edu/view/chemteam/ambertools_parmchk2/ecc43bf27a49)
- mmpbsa_mmgbsa was updated to [45dc2555933c](https://toolshed.g2.bx.psu.edu/view/chemteam/mmpbsa_mmgbsa/45dc2555933c)
- mmpbsa_mmgbsa was updated to [608098b3668d](https://toolshed.g2.bx.psu.edu/view/chemteam/mmpbsa_mmgbsa/608098b3668d)
- parmconv was updated to [5a97cb53a456](https://toolshed.g2.bx.psu.edu/view/chemteam/parmconv/5a97cb53a456)
- parmconv was updated to [6d0677a148fe](https://toolshed.g2.bx.psu.edu/view/chemteam/parmconv/6d0677a148fe)
- tleap was updated to [3de1359b86cc](https://toolshed.g2.bx.psu.edu/view/chemteam/tleap/3de1359b86cc)

## Data Managers

- data_manager_eggnog_mapper_abspath was updated to [fcb8bdd124f4](https://toolshed.g2.bx.psu.edu/view/galaxyp/data_manager_eggnog_mapper_abspath/fcb8bdd124f4)

## Proteomics

- eggnog_mapper was updated to [96cac424c870](https://toolshed.g2.bx.psu.edu/view/galaxyp/eggnog_mapper/96cac424c870)
- openms_openpepxl was updated to [a2a842b00f9c](https://toolshed.g2.bx.psu.edu/view/galaxyp/openms_openpepxl/a2a842b00f9c)
- openms_percolatoradapter was updated to [0fc9ae55bcfc](https://toolshed.g2.bx.psu.edu/view/galaxyp/openms_percolatoradapter/0fc9ae55bcfc)
- openms_percolatoradapter was updated to [e7881a82b56d](https://toolshed.g2.bx.psu.edu/view/galaxyp/openms_percolatoradapter/e7881a82b56d)
- openms_xfdr was updated to [81402a5e4173](https://toolshed.g2.bx.psu.edu/view/galaxyp/openms_xfdr/81402a5e4173)
- openms_xfdr was updated to [9a6e3bb0f358](https://toolshed.g2.bx.psu.edu/view/galaxyp/openms_xfdr/9a6e3bb0f358)

## Single-cell

- music_construct_eset was updated to [7902cd31b9b5](https://toolshed.g2.bx.psu.edu/view/bgruening/music_construct_eset/7902cd31b9b5)
- music_inspect_eset was updated to [577435e5e6b2](https://toolshed.g2.bx.psu.edu/view/bgruening/music_inspect_eset/577435e5e6b2)

## Imaging

- projective_transformation_points was updated to [3a686b6aa7fc](https://toolshed.g2.bx.psu.edu/view/imgteam/projective_transformation_points/3a686b6aa7fc)

repository: usegalaxy-eu/website

gha_language: TeX

repo_name: usegalaxy-eu/website


text:
---
id: glossary
title: Glossary of terms
sidebar_label: Glossary of Terms
---

List of terms necessary to understand the contents of this guide.

## **A**

### ACL (Access Control List)

A traffic filter of a list of networks and correlated actions used to improve security. Block or allow users to access specific resources.

* * *

### Acounts

An EOSIO account is a human-readable name that is stored on the blockchain. It can be owned by an individual or group of individuals depending on the configuration of the permissions. An account is required to transfer or send any valid transaction to the blockchain.

* * *

### Actions (EOSIO)

Functionality exposed by a smart contract that is exercised by passing the correct parameters through an approved transaction to an EOSIO network.

* * *

### Active Permission

Within account permissions, this is the owner's primary child permission by default. The active permit can perform all the actions of an account other than restructure the permission structure. It is one of the two default permissions that come with a new, proprietary and active account.

* * *

### Airdrop

A general method of placing tokens in EOS accounts. It is a distribution of a cryptocurrency token or coin, usually free, to numerous wallet addresses.

* * *

### Airgrab

The Airgrab model is designed to be a more capital efficient way to deploy dApp developer tokens. If you use the Airgrab token, it means you will use your own personal RAM and not the dApp developers like you do in an Airdrop, making it cheaper for the dApp developer.

* * *

### API

Set of functions and procedures that allow the creation of applications that access the characteristics or data of an operating system, application or other specific service.

* * *

## **B**

### Backend

Backend is the data access layer of a software, which is not directly accessible by users, it contains the logic of the application that handles said data. The Backend accesses the server, which is a specialized application that understands the way the browser requests information.

* * *

### Blacklist

A blacklist is a measure that a blockchain node can take to prevent it from blocking any transaction that has been authorized by a defined list of blocked accounts or any transaction that interacts with a defined list of contracts. Each node can define its own blacklist, which cannot be seen publicly.

* * *

### Block

Blocks are files where the data belonging to the blockchain is permanently recorded. They store some or all of the most recent transactions that have not yet entered any previous blocks. A block is a permanent store of records that once written cannot be altered or deleted.

* * *

### Block explorer

A block explorer is a program or website accessible through a browser that allows a user to search and navigate through the blocks of a blockchain, their contents and their relevant details.

* * *

### Block height

It is defined as the number of blocks in the chain between a given block and the first block in the block chain. For example a block height of 500 refers to block number 500 of that chain.

* * *

### Block one

Block.one is the company that created the EOSIO software. A producer of highly scalable, high-performance open source software, it is at the forefront of developing the next generation of the Internet.

* * *

### Block producer

Block producers are one of Block.one's main innovations, they are the decentralized entities that govern the EOSIO blockchain. Rather than being managed by a small number of mining groups, EOSIO will have a constantly changing group of 21 block producers.

* * *

### Block Rewards

Bitcoin block reward refers to the new bitcoins that are awarded by the blockchain network to eligible cryptocurrency miners for each block they mine successfully.

* * *

### Blockchain

A growing list of records, called blocks, that are linked by cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (usually represented as a Merkle tree).

* * *

### Bytecode canonical

It is used for communication between different data formats. A form of business application integration, it aims to reduce costs and standardize the agreed definitions of data associated with the integration of business systems

* * *

## **C**

### CDT (Contract Development Toolkit)

A complete smart contract development toolkit with a set of tools and utilities necessary for the development of EOSIO Smart Contracts. It provides support for the Gnu and C ++ 11 style by creating a more reliable way to declare your smart contract structure and associated data structures.

* * *

### Chain ID

A chain ID is a blockchain configuration that affects the formation of an address. The binary transaction link between the address and the chain ID makes it impossible to move transactions between different blockchain networks.

* * *

### Cleos

It is the command line tool that connects to the API exposed by nodeos and works to manage the wallet, account, keys, transactions and smart contracts.

* * *

### CPU

The CPU is processing power, the amount of CPU an account has is measured in microseconds (μs), it is known as CPU bandwith, the `cleos get account` command issues the amount of processing time an account has at its disposal by pressing actions to a contract.

* * *

## **D**

### DApps

They are digital applications or programs run on a blockchain or P2P computer network instead of a single computer, these are outside the reach and control of a single authority.

* * *

### DevOps

A set of practices that combines software development and IT operations. Its goal is to shorten the life cycle of systems development and provide continuous delivery with high-quality software.

* * *

### dfuse

A platform to train dapp developers with capabilities to create modern blockchain applications with fast and fluid interfaces that provide exceptional user experiences.

* * *

### Docker

A set of platform as a service products that uses virtualization at the operating system level to deliver software in packages called containers. Containers are isolated from each other and bundle their own software, libraries, and configuration files; they can communicate with each other through well-defined channels. All containers are run by a single core operating system, therefore using fewer resources than virtual machines.

* * *

### DPoS

A consensus algorithm developed to secure a blockchain, this by ensuring the representation of transactions within it. DPoS is designed as a technology-based implementation of democracy, using voting and election processes to protect blockchain from centralization and malicious use.

* * *

## **E**

### EOS

EOS is a decentralized blockchain-based system that enables the development, hosting, and execution of decentralized, commercial-scale applications (dApps) on its platform. EOS supports all the basic functions necessary to enable businesses and individuals to create blockchain-based applications in a similar way to web-based applications, such as providing secure access and authentication, permissions, data hosting, usage management, and communication. between dApps and the internet.

* * *

### EOS Hub

A mobile platform that offers the benefits of EOS to people.
It is an easy and secure way to help users access various EOS functions like tokens, voting, resource management, and RAM trading.

* * *

### EOS Rate

EOS Rate is an open source dApp that enables EOS token holders to rate Block Producers (BP) in just a few clicks. Users can access a rating system and voting portal, making it easy for token holders to make an informed decision.

* * *

### EOS Studio

EOS Studio is a unified graphical IDE to accelerate dApps development Integrated with various tools necessary for EOSIO.

* * *

### EOSCR

EOS Costa Rica is a startup derived from the pioneering company Sistemas Edenia Internacional SA, established in 1987 and operating as a blockchain infrastructure provider since 2013. At EOS Costa Rica we manage the infrastructure for EOSIO networks and develop dApps that emphasize individual sovereignty and promote business adoption. We also provide an open platform for developers to innovate, as well as training programs to increase opportunities in the blockchain space.

* * *

### EOSIO

EOSIO is a blockchain designed to facilitate the operation of a new type of program called decentralized application (dapp).
Its technology attempts to solve historical problems by using blockchains to run dapps, as popular apps have even clogged up the capacity on larger and more developed blockchains, resulting in performance issues for all users.

* * *

### EOSJS

A library created to easily control the EOS blockchain with Javascript. It can be said that it was made to easily use the `EOS HTTP API (nodeos)`. (web3.js on Ethereum, neon-js on Neo)

* * *

### EOSQ

A highly accurate block explorer that provides access to accurate, detailed and actionable data on accounts, stocks and block producers.

* * *

## **F**

### Fiat

Trust money (fiat) is a government-issued currency that is not backed by a physical product, such as gold or silver, but by the government that issued it.

* * *

## **G**

### Genesis JSON

genesis.json is the file that defines the `Genesis block`, which is the starting block of the blockchain. This is like the "configuration" of your blockchain. For example, the chain configuration and the level of difficulty to extract blocks.

* * *

### GitHub

A platform that provides hosting for version control of software development, in addition, it allows to manage distributed version control and the functionality of source code management, as well as its own characteristics. It provides access control and various collaboration features such as bug tracking, feature requests, task management, and wikis for each project.

* * *

### GraphQL

An API query language, it uses a runtime to populate those queries with your existing data. GraphQL provides a comprehensive and understandable description of the data in your API, gives customers the power to ask for exactly what they need and nothing else, makes APIs evolve over time, and enables powerful developer tools.

* * *

## **H**

### Hackathon

`Hackathon` is an event (competition) in which computer programmers, graphic designers, interface designers, project managers meet and try to work on projects related to technology and specific problems.

* * *

### Hapi

A backend service for custom business logic, integrated with Hasura, using actions

* * *

### Hardware biometric

These are technological devices that allow biometric data from humans or other objects to be perceived, an example of this is the easy recognition that some security cameras and mobile devices have, also the unlocking of artifacts by means of fingerprints, to mention Some.

* * *

### Hash

`Hash` is the process of transforming a string into a fixed-length key or value. A data string will always produce the same hash, so it is used as a means of checking the content of the string against the expected content.

* * *

### Hasura

An ultra-fast GraphQL server that offers you real-time GraphQL API over Postgres, with webhook triggers on database events and remote schemas for business logic.

It also helps build Postgres-supported GraphQL applications or gradually move to GraphQL for existing applications that use Postgres.

* * *

### Head Block

The `Head Block` is the last block written on the blockchain, stored in reversible blocks.

* * *

### Httpie

Is an easy to use command line HTTP client for the API era. It comes with JSON support, syntax highlighting, persistent sessions, wget downloads, plugins, and more.

* * *

## **I**

### IAC (Infrastructure as code)

Is the process of managing computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.

* * *

### IBC (Inter-Blockchain Communication)

A tool by which multiple blockchains can communicate with each other. This can be used to send tokens from one chain to another, or to expand the capacity of a network by increasing the number of chains running in parallel.

* * *

### ICO Inter Blockchain Communication

Popular method of distributing the initial supply of coins (tokens) by selling them in exchange for fiat currency or other cryptocurrencies.

* * *

### Immutable

Term used to refer to something that cannot be changed.

* * *

### Inline Action

`Inline actions` are actions that are created within a smart contract. A single action that a user authorizes can then create many subsequent actions that will execute within a single transaction, or create deferred transactions as well.

* * *

### IPFS

It is a distributed storage mechanism for putting files online for decentralized storage.

* * *

### Issue

`Issues` are a great way to track tasks, improvements and bugs for your projects through the GitHub platform.

* * *

## **J**

### Jq

 Is a lightweight and flexible command line to process JSON files.

* * *

### Jungle Testnet

The `Jungle TestNet` was initiated by and has served as sandbox for many development teams and EOS Block Producers since the birth of EOSIO.

* * *

## **K**

### Kanban

A `Kanban` board is a tool that allows us to visualize a team workflow, creating columns with the most important stages of project development. It assigns tasks to team members, allowing a better organization of time and resources.

* * *

### KEOSD

`keosd` is the component that securely stores EOSIO keys in wallets.

keosd = key + eos

* * *

### Kubernetes

`Kubernetes` is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

* * *

## **L**

### LACCHAIN

`LACChain` is an initiative by IDB Lab (part of the Inter-American Development Bank) to accompany and accelerate the development of the blockchain ecosystem in Latin America. It aims to establish national consortiums in the region, to develop and promote standards for interoperability of networks, and to develop and maintain interoperable blockchain infrastructures.

* * *

### LatamLink

`LatamLink` is a voluntary regional alliance led by Latin American technology companies. We develop an EOSIO-based testnet for the LACChain network to highlight the benefits of this technology. LACChain EOSIO deploys a public permissioned version of EOSIO technology for Latin American developers and organizations to test their decentralized applications and infrastructure.

* * *

### Latency

Period of time that elapses between the communication of a packet through the network.

* * *

### Launch

The term used to signify the beginning of a blockchain.

* * *

### LIB (Last irreversible block)

A block is considered irreversible (i.e. immutable) on an EOSIO based blockchain when 2/3rd of the currently elected block producers have acknowledged it.

* * *

## **M**

### Mainnet

`Mainnet` is the main EOSIO blockchain under the `ChainID: aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906`.

Since EOSIO software is open source and available for free, there may be many instances of it.

* * *

### Merkle Tree

A `Merkle Tree` is a tree in which every leaf node is labelled with the hash of a data block, and every non-leaf node is labelled with the cryptographic hash of the labels of its child nodes. Hash trees allow efficient and secure verification of the contents of large data structures.

* * *

### Micro Fork

A microfork occurs when a Block Producer begins to produce blocks with the same block height as a block that was recently produced.

* * *

### Multi-Sig

`Multisig` is a short term for multiple signatures.It’s used to describe the case in which one requires more than one account's permission to execute a transaction.

* * *

## **N**

### Network

`NET` is a very important resource in EOSIO based blockchains. It is the network bandwidth (measured in bytes) required to store transactions on a blockchain.

* * *

### Nodeos

`Nodeos` is the core EOSIO node daemon that can be configured with plugins to run a node. Example uses are block production, dedicated API endpoints, and local development.

nodeos = node + eos

* * *

### Nodos

`node` is the fundamental basis of blockchain technology, they make up the infrastructure of a blockchain. All nodes in a blockchain are connected to each other and constantly exchange the latest data in the blockchain so that all nodes are kept up to date.

* * *

### NPM

[NPM](https://nodejs.org/en/knowledge/getting-started/npm/what-is-npm/) `Node Package Manager` is an online repository for publishing open source projects, it also allows the installation of packages, version administration and dependency administration.

* * *

## **O**

### Oracle

An oracle is a system that makes off-chain data available on-chain. An example of this would be an oracle that takes the score of a basketball game and puts it on-chain for smart contracts to consume and base decisions on.

* * *

### Owner Permission

Within the permissions structure of an account, owner is the top-level authority. The owner permission can sign on behalf of, and restructure, all lower-level permissions. It is one of two default permissions that come with a new account, owner and active.

* * *

## **P**

### Permissions

A weighted security mechanism that determines whether or not a message is properly authorized by evaluating its signature(s) authority.

* * *

### Podcasts EOS

A set of EOS-related sites where new content is constantly being added to channels. This content can be in video, audio, or blog format.

* * *

### Private Key

A `private key` is a secret key used to sign transactions. In EOSIO, a private key's authority is determined by it's mapping to an EOSIO account name.

* * *

### Proof of Work

`Proof of Work` is a consensus mechanism used by many blockchains, most notably by Bitcoin. The miner of the next block is the first to solve a hashing problem. The difficulty of this problem increases as more hashing power attempts to solve this problem at the same time. The ever-increasing amount of work that has gone into a blockchain over time is what protects the chain's history.

* * *

### Proxy

The actual act of delegating your vote towards another account. If a user does not want, or have the available time, to research which Block Producers should receive their vote (but still wants to participate in voting), they can proxy their vote strength towards another account.

* * *

### Public Key

A publicly available key that can be authorized to permissions of an account and can be used to identify the origin transaction. A `public key` can be inferred from a signature.

* * *

### Pull request

`Pull requests` let you tell others about changes you've pushed to a branch in a repository on GitHub.

Once a `pull request` is opened, you can discuss and review the potential changes with collaborators and add follow-up `commits` before your changes are merged into the base branch.

* * *

## **Q**

## **R**

### RAM

`RAM` is required to store account information such as keys, balances, and contract state on an EOSIO based blockchain.

* * *

### Resources

EOSIO accounts have three types of resources that they must maintain: `RAM`,` CPU` and `Net`

* * *

### REX

The `REX` (Resource Exchange) is a CPU and Network resource rental market in which holders of the core token of a blockchain can buy and sell slices of the REX pool in the form of REX tokens. Blockchain users can then rent CPU and Network resources from the REX pool.

* * *

### Ricardian Contract

In the EOSIO based blockchain context `Ricardian Contract` is a digital document that accompanies a smart contract and defines the terms and conditions of an interaction between the `smart contract` and its users, written in human readable text, which is then cryptographically signed and verified. It is easily readable for both humans and programs, and aids in providing clarity to any situations that may arise in the interactions between `smart contract` and its users.

* * *

## **S**

### Smart Contract

A `smart contract` is a computer protocol intended to facilitate, verify, or enforce the negotiation or performance of a contract.

* * *

### Snapshot

At any given point in time, a `Snapshot` of the total state of the chain can be taken. For example, this could be used by a token that wants to `airdrop` to all current `token` holders based on their current holdings.

* * *

### SPOF

Part of a system that if it fails to detect the operation of the entire system. These are not desirable in any system with a goal of high availability or reliability.

* * *

### Squash merge

Squash merging is a `merge` option that allows you to condense the Git history of topic branches when you complete a `pull request`. Instead of each `commit` on the topic `branch` being added to the history of the default `branch`, a squash merge takes all the file changes and adds them to a single new `commit` on the default `branch`.

* * *

### Stablecoin

A `token`whose value is intended to remain stable.  This can be done by pegging to another currency or token, or algorithmically. Many stablecoins peg to the US dollar, meaning that one token should always be redeemable for one US dollar.

* * *

### Stake

Your total `EOS token` holding is referred to as your stake.

* * *

### Standby BP

A set of about 100 full nodes that have expressed the desire to be selected as block producers, and are capable of doing so on demand. Whenever the chain needs to replace an existing BP with a new one, the new one is drawn from the standby pool.

* * *

### StoryBook

[StoryBook](https://storybook.js.org/) is an open source tool for developing UI components in isolation for React, Vue, and Angular.

* * *

### System Account

These are accounts that begin with the prefix eosio.* and hold either the code or the funds for native blockchain actions (such as voting, multisig, account creation, and so on).

* * *

## **T**

### TaPoS - Transaction as Proof of Stake

` TaPoS`  is used to ensure that a user fetches the recent state of the top of the blockchain to prove that they are aware of the state of the chain when signing a transaction. This helps to prevent certain forms of attacks, such as a replay attack where a malicious user tries to replay a transaction, despite the state of the associated accounts having already been changed.

* * *

### Telos

[Telos](https://www.telos.net/) is a blockchain platform without high-performance permissions for decentralized applications with advanced data storage and governance functions.

* * *

### Terraform

[Terraform](https://www.terraform.io/) it is a tool to build, change and version infrastructure in a safe and efficient way. Terraform can manage existing and popular service providers as well as custom internal solutions.

* * *

### TestNet

A test network or `testnet` is an instantiation of the EOSIO platform that is intended for testing purposes. Generally, the native token has no value and is given away to developers so they can test.

* * *

### Tokens

The unit of measurement of a cryptocurrency.

* * *

### TPS

A metric by which the performance of a blockchain is measured.

* * *

### Transactions

It is a combination of one or more actions. Usually the result of executing a `smart contract`.

* * *

## **U**

### UAL (Universal Authenticator Library)

Developed by EOSIO Labs, the [Universal Authenticator Library (UAL)](https://github.com/EOSIO/universal-authenticator-library) allows app developers to integrate with a variety of authenticators (wallets, app explorers, key managers, etc.) by coding to a single, universal API.

* * *

### UX Design

It is the design process that development teams use to create products that provide enjoyable experiences for users.

* * *

## **V**

### Vote

Voting is a fundamental part of the system. The most widely used application of voting is to elect which Block Producers will actually produce blocks for the network. Voting will also be used to help collect the communal decisions through which we will change the course of the network.

* * *

### Vote Decay

To discourage users from casting a vote for Block Producers and then not updating their `vote` periodically, a decay in the relative vote strength of old votes was introduced. To maintain maximum vote strength, a user should vote at least once per week.

* * *

## **W**

### Wallet

`Wallets` are clients that store keys that may or may not be associated with the permissions of one or more accounts. Ideally a wallet has a locked (encrypted) and unlocked (decrypted) state that is protected by a high entropy password.

* * *

### Wasm

The EOSIO based blockchains execute user-generated applications and code using WebAssembly.

`WASM` is an emerging web standard with widespread support of Google, Microsoft, Apple, and others. At the moment the most mature toolchain for building applications that compile to WASM is clang/llvm with their C/C++ compiler.

* * *

### Whitelist

A whitelist is a subjective measure that a blockchain node can implement to allow transactions to be placed in a block only if they are listed in your account or contract whitelist. Each node can specify its own whitelist, which cannot be seen publicly.

* * *

## **X**

* * *

## **Y**

### Yarn

[Yarn](https://yarnpkg.com/) is a package manager for web projects that supports the npm package manager structure (package.json y node_modules)

* * *

## **Z**

### Zeplin

[Zeplin](https://zeplin.io/) is a collaborative tool for designers and Front-End developers that allows a workflow in which they can create designs, facilitating communication, and better organization of time.

* * *

gha_language: JavaScript


text:
This series
is for you! It assumes you know nothing and takes you from soup to nuts
on how to bootstrap trust with the intent to power a Zero Trust security
model. The process and thinking described in this series are the direct
output of developing the same system for the Ziti open source project.
Ziti can be found on the GitHub project page for
[OpenZiti](https://github.com/openziti). The series starts with the
basics and dovetails into Ziti's Enrollment system.

The parts are as follows.

- [Part 1: Encryption Everywhere](./part-01.encryption-everywhere.md)
- [Part 2: A Primer On Public-Key Cryptography](./part-02.a-primer-on-public-key-cryptography.md)
- [Part 3: Certificates](./part-03.certificates.md)
- [Part 4: Certificate Authorities & Chains Of Trust](./part-04.certificate-authorities-and-chains-of-trust.md)
- [Part 5: Bootstrapping Trust](./part-05.bootstrapping-trust.md)

### Zero Trust

This entire series assumes some familiarity with Zero Trust. If you do
not have a strong background in it, that is fine. This section should
give the reader enough context to make use of the entire series. If a
more in-depth understanding is desired, please consider reading *Zero
Trust Networks: Building Secure Systems in Untrusted Networks* by Evan
Gilman.

Zero Trust is a security model that requires strict identity
authentication and access verification on every connection at all times.
It sets the tone for a system's security to say, "this system shall
never assume the identity or access of any connection." Before the Zero
Trust security models, IT infrastructures were set up as a series of
security perimeters. Think of as a castle with walls and moats. The
castle would have a set number of entry points with guards. Once past
the guards and inside the castle, any visitors were trusted and had
access to the castle. In the real world, passing the guards is analogous
to authenticating with a machine or, at worst, connect the office
network via WiFi or ethernet cable.

Zero Trust does away with the concept of having a central castle that
assumes anyone inside is trusted. It assumes that the castle has already
been breached. That is to say, we expect attackers to already be inside
the network and for it to be a hostile environment. Any resources inside
the network should be treated as being publicly available on the
internet and must be defended. To accomplish this defense, a series of
Zero Trust pillars are defined:

- Never Trust, Verify - the virtue of a connection should not grant
  access
- Authenticate Before Connect - authentication should happen before
  resources are connected to
- Least Privileged Access - access should only grant connectivity to the
  minimum number of resources

Implementing those pillars is not a simple tweak to existing
infrastructure. The first point alone will have much of this series
dedicated to it.

### Ziti & Zero Trust

In a Zero Trust model, there needs to exist mechanisms to verify
identities such that trust can be granted. Zero Trust does not mean
there is no trust. Zero Trust means that trust is given only after
verification. Even then, that trust is limited to accessing the minimum
network resources necessary. To accomplish this, we need a network that
can force all connections through the following process.

1. Authenticate
2. Request Access To A Resource
3. Connect To The Requested Resource

This process is not the typical connection order on a network. Most
connections on a network are done in the reverse order. At first, this
may seem counter-intuitive. To help make Zero Trust and bootstrapping
trust a bit clearer, it helps to have a concrete system to use an
example. It just so happens that the Ziti software system makes a great
example!

![Ziti System](./images/ziti-system.png)

In Ziti, all of the above steps require interacting with a Ziti
Controller. The Ziti Controller manages the Ziti overlay network by
maintaining a list of known network services, SDK clients, routers,
enrollments, policies, and much more! All of these pieces working
together to create a Ziti Network. A Ziti Network is an overlay network
\- meaning it creates a virtual network on top of a concrete network.
The concrete network may be the internet, a university network, or your
own home network. Whatever it is, it is referred to as the underlay
network.

In the Ziti Network, all network resources are modeled as services in
the Ziti Controller. All services on a Ziti Network should only be
accessible via the Ziti Network for maximum effect. Network services can
be made available via a Ziti Network in a variety of manners. The
preferred method is embedding the Ziti SDK inside of applications and
servers as it provides the highest degree of Zero Trust security.
However, it is also possible to configure various overlay-to-underlay
connections to existing network services via "router termination" or a
particular type of application with the Ziti SDK embedded in it that
specifically deals with underlay-to-overlay translations (i.e. Ziti
Desktop Edge/Mobile Edge).

The Ziti Controller also knows about one or more Ziti Routers that form
a mesh network that can create dynamic circuits amongst themselves.
Routers use circuits to move data across the Ziti Network. Routers can
be configured to allow data to enter and exit the mesh. The most common
entry/exit points are Ziti SDKs acting as clients or servers.

Network clients wishing to attach to the network use the Ziti SDK to
first authenticate with the Ziti Controller. During authentication, the
Ziti SDK client and Ziti Controller will verify each other. Upon
successful authentication, the Ziti Controller can provide a list of
available services to dial (connect) or to bind (host) for the
authenticated SDK Client. The client can then request to dial or bind a
service. If fulfilled, a session is associated with the client and
service. This new session is propagated to the necessary Ziti Routers,
and the required circuits are created. The client is returned a list of
Ziti Routers which can be connected to in order to complete the last
mile of communication between the Ziti overlay network and the SDK
client.

This set of steps covers the pillars of the Zero Trust model! The Ziti
Controller and SDK Clients verify each other. The client cannot connect
to network resources or services until it authenticates. After
authentication, a client is given the least privilege access allowed by
only being told about and only being able to dial/bind the authenticated
identity's assigned services. It is a Zero Trust overlay network!

How did this system come into existence? How do the Ziti SDK client and
Ziti Controller verify each other? How do the routers and controller
know to validate each other? How is this managed at scale with hundreds
of Ziti Routers and thousands of Ziti SDK clients? It seems that this is
a recursive problem. To terminate the recursion, we have to start our
system with a well-defined and carefully controlled seed of trust.

# Trust

In software systems that require network connectivity, there are at
least two parties in the system. Generally, there are more, and in the
case of a Ziti network, there could be thousands. Between two parties,
each time a connection is made, a trust decision is made. Should this
connection be allowed? Mechanisms must be put into place to verify the
identity of the connecting party if that question is to be answered.

One mechanism that might jump out at the reader is a password or secret.
In Ziti, it would be possible to configure the Controller, Routers, and
SDK Clients with a secret. Software is easy to deploy with a secret.
Throw it into a configuration file, point the software at, and off you
go!

It is also fundamentally weak as there is only one secret in the system
necessary to compromise the entire system. In Ziti, this would mean
giving the secret to network clients that may or may not be owned by the
network operator. Also, shared secrets do not individually identify each
component, nor do they define how secrets will power other security
concerns, like encryption.

The solution can be improved. Secrets could be generated per software
component. The controller, each router, and each SDK client could have a
unique secret. This secret would then individually identity each
component! It is a significant improvement, but how does each component
verify connections? Do they challenge for the incoming connections
secret and compare it to a list? That means that a pair of systems that
need to connect must have each other's secrets. Secret sharing will not
do! We can not be copying secrets between every machine. One machine
that is compromised would mean that many secrets are revealed!

This solution can be evolved and improved, but we do not have to do that
hard work! If we did, we would end up recreating an existing technology.
That technology is (public-key
cryptography)[https://en.wikipedia.org/wiki/Public-key_cryptography],
and it provides everything we need.

Public-key cryptography allows each device to have a unique, secret,
private key that proves its unique identity. That private key is
mathematically tied to a public key. The public key can be used to
encrypt messages that only the private key holder can decrypt. Also, the
public key cannot be used to derive the original private key. This
functionality fits perfectly with what our distributed system needs!
Alas, public-key cryptography introduces complex behaviors, setup, and
management. In the next article, we will dive a little deeper into this
topic. For now, let us take it on faith that it will serve our needs
well.

#### Setting It Up

So we have decided that public-key cryptography is the answer. What does
that mean? What do I have to do? Let us explore what would need to be
done by a human or a piece of software automating this process. Don't
worry if you don't get all of this; the gist is all you need for now.
Later articles will expand upon this terminology. In fact, after reading
the later articles, consider revisiting this part.

Consider the following diagram of a "mesh" distributed system. This mesh
could be any type of system such as a mesh of Ziti Routers, or maybe it
is a system of sensors on an airplane. What they do does not matter.
What matters is that this system has multiple pieces of software
connecting amongst themselves. Consider what it means to accomplish this
using public-key cryptography.

![Mesh](./images/mesh.png)

In the diagram above, each system needs:

- a key pair for client and server connections
- to have the public keys of each system it is connecting to

So what do we need to do? Drop into a CLI and start generating keys on
each machine. Do that by using these commands:

```
openssl ecparam -name secp256k1-genkey -param_enc explicit -out private-key.pem
```

```
openssl req -new -x509 -key private-key.pem -out server.pem -days 360
```

Voila - you now have a self-signed certificate! What is a self-signed
certificate? For now, let us understand it means that no other system
has expressed trust in your public certificate. In
[Part 4: Certificate Authorities & Chains Of Trust](./part-04.certificate-authorities-and-chains-of-trust.md)
we will cover them in more detail.

You can repeat the above process for every piece of software in your
mesh network. Preferably, you log into each machine and generate the
private key there. Moving private keys on and off devices is a security
risk and frowned upon. For maximum security, hardware, such as
[Hardware Security Modules (HSMs)](https://en.wikipedia.org/wiki/Hardware_security_module)
and [Trusted Platform Modules
(TPMs)](https://en.wikipedia.org/wiki/Trusted_Platform_Module), can be
used to store the private keys in a manner that does not make them
directly accessible.

Then you will need to copy each public certificate to every other
machine and configure your software so that it trusts that certificate.
The system will need to repeat this process any time the system adds a
piece of software. If a machine is compromised, the analogous public
certificate will need to be untrusted on every node in the mesh. Adding
or removing trust in a public certificate involves configuring software
or operating systems. There are many ways it can be implemented,
including configuration files, files stored in specific directories, and
even via configuration tools such as Windows Certificate Manager
snap-in.

This is a log of careful work to get a simple system running. Consider
what this means when adding or removing many nodes? Visiting each
machine and reconfiguring them each time is quite a bit of overhead.
There is a solution to these woes. While it is elegant on its own, it
does add complexity. Let us see how Certificate Authorities (CAs) can
help! In the next section, we will hit the highlights of CAs. For more
detail, look forward to
[Part 4: Certificate Authorities & Chains Of Trust](./part-04.certificate-authorities-and-chains-of-trust.md).

#### CAs & Adding Complexity

A CA enables trust deferral from multiple individual certificates to a
single certificate which means that instead of trusting each
certificate, each piece of software will trust the CA. The CA will be
used to sign every public certificate our software pieces need to use.
How does "signing" work? We will cover that in
[part three](./part-03.certificates.md) and why it matters part in
[four](./part-04.certificate-authorities-and-chains-of-trust.md). For
now, the basics will be provided.

Here are the high-level steps of using a CA:

1. create a CA configuration via OpenSSL CNF files
2. create the CA
3. use the CA's public key to sign all of the public certificates
4. distribute the CA's certificate to every machine
5. configure the machines certificate store or configure the software

For items one and two, the process can be a bit mystical. There is a
multitude of options involved in managing a CA. To perform number three,
you will need to go through the processing of creating certificate
signing requests (CSRs, see [parts three](./part-03.certificates.md) for
more detail) on behalf of the piece of software, and someone or
something will have to play the role of the CA and resolve the CSRs. The
last two steps will depend on the operating system and software being
used.

All of these actions can be done via a CLI or programmatically. You will
have to spend time and energy, making sure the options are correctly set
and learning about all the different capabilities and extensions.
Mistakes will inevitably occur. It is time-consuming to debug why a
specific public certificate is not working as intended. The tools and
systems that use the certificates are purposely vague in error messages
as not to reveal too much information to attackers.

The payoff for using CAs is having the ability to create chains of
trust. Chains of trust allow distributed systems to scale without having
to reconfigure each node every time the system grows or shrinks. With a
little more upfront cost and bookkeeping to run a CA, the system will
greatly decrease the amount of configuration required on each device.

#### Further Concerns

Once configured, there are still other concerns that need to be taken
into account. Consider the following list of events that may happen to a
CA, and it's certificates:

- What happens when a certificate expires?
- How does a system know not to trust a certificate anymore?
- What happens when private keys need to regenerate?

CAs do not automatically handle the propagation of these types of
events. CAs are files on a storage device or HSM. Issuing or revoking
certificates does not generate any kind of event without additional
software. There is also the issue of certificates expiring. That "-days
360", used in the example above, puts a lifetime on each certificate.
The lifetime can be extended far into the future, but this is a bad
practice. Limiting the life span of a certificate reduces attack windows
and can be used as a trigger to adopt strong encryption.

Even if we ignore all of those concerns, who did we trust to get this
system setup? What was the seed of trust used to bootstrap trust? So
far, you could have imagined that a human was doing all of this work. In
that case, a human operator is trusted to properly configure all of the
systems - trusting them with access to all of the private keys. The seed
of trust is in that human. If this is a software system performing these
actions, that means that the system has to be trusted and most likely
have access to every other system coming online. That is workable, but
what happens when your system can have external systems request to be
added to the network? How can that be handled? How do you trust that
system in the first place? Using a secret password creates a single,
exploitable, weak point. Public-key cryptography could be put in place,
but then we are in a chicken-and-egg scenario. We are putting public-key
cryptography in place to automate public-key cryptography.

There are many caveats to bootstrapping trust. In a dynamic distributed
system where pieces of software can come and go at the whim of network
operators, the issues become a mountain of concerns. Thankfully in Ziti,
a mechanism is provided that abstracts all of these issues. To
understand how Ziti accomplishes this, we have a few more topics to
discuss. In
[part two](./part-02.a-primer-on-public-key-cryptography.md), we will
chip away at those topics by covering public-key cryptography in more
detail to understand its powers and applications.

---

Written By: Andrew Martinez
June 2020

repository: dovholuknf/ziti-doc

repo_name: dovholuknf/ziti-doc


text:
# Contributing

When contributing to this repository, we would really like you to first discuss the change you wish to make via raising an issue or sending an email to the team behind this project.

Please note we have a code of conduct, please follow it in all your interactions with the project.

## Pull Request Process

1. Ensure any install or build dependencies are removed before the end of the layer when doing a build.
2. Update the README.md if required, with details of changes to the build process.
3. Increase the version numbers in any examples files and the README.md to the new version that this Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/).
4. Pull requests will be merged by the project owner.

repository: MicroPasts/bronze-age-index

repo_name: MicroPasts/bronze-age-index


text:
# [can-a-robot-do-your-job](https://ig.ft.com/can-a-robot-do-your-job)

> Calculator to show how much of your job could be done by a robot

## Local

1. Install NPM modules with npm (`npm install`) or yarn (`yarn`).
2. Run `npm start`, which does a build/compile, starts a dev server and watches for changes.

# Deploy

1. Write code in a branch.
2. Make a PR. CI will automatically:
    * build and test the branch
    * deploy green builds to the review site
3. Do quick smoke testing of the review build
4. Get a code review. Once you get a thumbs up, merge into master.
5. CI will build, test and deploy a build to Production.

## Uses Starter Kit

This project was scaffolded with [Starter Kit @be83d0b](https://github.com/ft-interactive/starter-kit/tree/be83d0b).

## Licence
This software is published by the Financial Times under the [MIT licence](http://opensource.org/licenses/MIT).

Please note the MIT licence includes only the software, and does not cover any FT content made available using the software, which is copyright © The Financial Times Limited, all rights reserved. For more information about re-publishing FT content, please contact our [syndication department](http://syndication.ft.com/).

repository: ft-interactive/can-a-robot-do-your-job

repo_name: ft-interactive/can-a-robot-do-your-job


text:
# Project Title

A react accessories library for making CRUD restful call and handling authentication

## Getting Started

no content yet

### Installing

no content yet

## Usage

```
import { AuthContextProvider, useAuthContext } from "react-accessory";

interface User {
  name: string;
  iat: number;
}
function Child() {
  const auth = useAuthContext<User>();
  const { handleTokenChange, userInfo, token, isLogined } = auth;
   return (
        <>
          <pre>{JSON.stringify(userInfo, null, 4)}</pre>
          <button onClick={() => handleTokenChange('')}>logout</button>
        </>
  );
}

function App() {
  return (
    <AuthContextProvider defaultUser={{ name: "", iat: -1 }}>
      <Child />
    </AuthContextProvider>
  );
}
```

### Authentication
* `handleTokenChange`: actively update token, can be used for logout
* `userInfo`: decoded information inside token
* `isLogined`: true if token is not empty

## Built With

* [React](http://https://reactjs.org/) - A JavaScript library for building user interfaces

## Authors

* **Shun Kong Cheung** - *Initial work* - [shunkongcheung](https://github.com/shunkongcheung)

See also the list of [contributors](https://github.com/shunkongcheung/react-accessories) who participated in this project.

## License

This project is licensed under the MIT License - see the [LICENSE.md](LICENSE.md) file for details

## Acknowledgments

* Create based on [this](https://www.pluralsight.com/guides/react-typescript-module-create) example

repository: shunkongcheung/react-accessories

gha_language: TypeScript

repo_name: shunkongcheung/react-accessories


text:
File Metadata Microservice
-----

By Luca Perico for [FreeCodeCamp](https://www.freecodecamp.com/challenges/file-metadata-microservice)

##### User story
1. I can submit a FormData object that includes a file upload.
2. When I submit something, I will receive the file size in bytes within the JSON response

##### Example input:
1. A file
##### Example output:
1. {'size': 4}`

##### Project Files
 * server.js: HTTP server listening for the file

##### Howto

`node server.js` : start the NodeJS server

`note test.js` : test the module timeservice

###### The server is usually down!

repository: LucaPericoIT/FileMetadataService

repo_name: LucaPericoIT/FileMetadataService


text:
# WaterRocket
## Description
Simple parachute deployment for a water rocket.
Was tested on the 29 August and used during the Swiss Water Rockets Championship 2017.
## Authors
Assembly and design: Paul Megevand

Electronics and Programming: Thomas Lew
## How to use it?
Compile the project on your computer with the Arduino standard IDE:

https://www.arduino.cc/en/Main/Software

and upload it to your microcontroller from this program.

For the Arduino pro mini such as the one used here, use an USB adapter (such as the FT232RL )
## Hardware
For the brain of the project, an arduino pro mini was used. Any board would work, just don't forget to set the pins right in the code.

To connect it to a computer for programming it, we used a FT232RL.

![alt text](https://github.com/thomasjlew/WaterRocket/blob/master/images/ft232rl.jpg)

Finally, you need an Inertial Measurement Unit to detect takeoff. We used the MPU6050.

![alt text](https://github.com/thomasjlew/WaterRocket/blob/master/images/mpu6050.jpeg)

## Sample water rocket with electronics mounted
![alt text](https://github.com/thomasjlew/WaterRocket/blob/master/images/water_rocket.jpg)

## Deployment
Right now, it works with a timer set to 5 seconds. Once the water rocket takes off, it is detected which starts the timer to realease the parachute after 5 seconds.

repository: thomasjlew/WaterRocket

repo_name: thomasjlew/WaterRocket