<commit_before>homepage: ''
changelog-type: markdown
hash: 93d5e72b7b2edc05e1a4b9926581bcf1bddbdeb940ac8cda4460aa1939406ef2
test-bench-deps:
  base: ! '>=4.7 && <5'
  pi-hoole: -any
maintainer: lthms <<EMAIL>>
synopsis: Lightweight access control solution for the pijul vcs
changelog: ! '# Changelog for pi-hoole


  ## Unreleased changes

'
basic-deps:
  warp: ! '>=3.0 && <3.3'
  regex-pcre: ! '>=0.91 && <0.95'
  bytestring: ! '>=0.10 && <0.11'
  wai: ! '>=3.0 && <3.3'
  optparse-generic: ! '>=1.0 && <1.4'
  unix: ! '>=2.0 && <2.8'
  base: ! '>=4.7 && <5'
  text: ! '>=1.0 && <1.3'
  megaparsec: ! '>=5.0 && <6.6'
  filepath: ==1.4.*
  process: ! '>=1.0 && <1.7'
  containers: ! '>=0.5.9 && <0.6'
  base58-bytestring: ! '>=0.1 && <0.2'
  pi-hoole: -any
  http-types: ! '>=0.9 && <0.13'
  aeson: ! '>=1.0 && <1.4'
  yaml: ==0.8.*
  directory: ! '>=1.2 && <1.4'
all-versions:
- '0.1.0.0'
author: <NAME>
latest: '0.1.0.0'
description-type: markdown
description: ! "# pi-hoole\n\n`pi-hoole` is a collection of tools to enforce access
  control for self-hosted\npijul repositories. It can be seen as a cgit-like solution,
  for authenticated\n(public key, SSH) and anonymous accesses. You can grant read
  and write accesses\nto a whole repository, or to a determined subset of branches.\n\n`pi-hoole`
  is distributed under the terms of the AGPL v3.\n\n## Getting Started\n\n### Building
  From Source\n\nIt should not be a surprise that `pi-hoole` is versioned under `pijul`,
  with the\npatch format introduced by `pijul-0.9`. Fair warning, use `pijul-0.10.1`
  and you\nshould be able to clone the `pi-hoole` repository.\n\n```bash\npijul clone
  https://pijul.lthms.xyz/pijul/pi-hoole\n```\n\nUnder the hood, `pi-hoole` is implemented
  in Haskell. We will need `stack` to\nbuild it.\n\n```bash\ncd pi-hoole\nstack build\n```\n\nWe
  are using the latest lts available, but `pi-hoole` has already been built\nwith
  `lts-10` (but does not build with older ones).\n\nThis build three executables:\n\n*
  `pi-hoole-cfg` generates a `.authorized_keys` file to enforce access control\n  for
  SSH.\n* `pi-hoole-shell` is called to determine if a authenticated user is allowed
  to\n  perform a given `pijul` command.\n* `pi-hoole-web` is a HTTP proxy to enforce
  access control for anonymous\n  requests.\n\n### Installing\n\nIn order to use `pi-hoole`
  on your server, the first step is to create a new,\ndedicated user (*e.g.* `pijul`).
  You then need to make `pijul` and\n`pi-hoole-shell` available to this user. Currently,
  we do not provide any\npackaging solution to that end, but this might change in
  the future. Although it\nis not mandatory, we consider both `pi-hoole-cfg` and `pi-hoole-web`
  have also\nbeen made available for the `pijul` user.\n\n### Configuring\n\n`pi-hoole`
  executables assume the configuration files are stored at\n`${XDG_CONFIG_DIRECTORY}/pi-hoole`,
  that is `~/.config/pi-hoole` by default.\n\nIn this directory, `pi-hoole` will scan
  the `keys/` directory, if it exists,\nto know the list of authorized authenticated
  users. One user may have as many\npublic key as required. Keys should be saved in
  file with the following filename\nscheme: `<user>(\\.<label>)?\\.pub`. Thus, `lthms.pub`,
  `lthms.laptop.pub` and\n`lthms.work.pub` are three valid public key filenames for
  the `lthms` user.\n\nTo generate a `.ssh/authorized_keys`, use `pi-hoole-cfg`.\n\n```bash\npi-hoole-cfg
  generate > ~/.ssh/authorized_keys\n```\n\nResulting file will be of the forms:\n\n
  \   command=\"pi-hoole-shell \\\".lthms\\\" \\\"${SSH_ORIGINAL_COMMAND}\\\"\",no-port-forwarding,no-x11-forwarding,no-agent-forwarding
  <ssh_keys_1>\n    command=\"pi-hoole-shell \\\".lthms\\\" \\\"${SSH_ORIGINAL_COMMAND}\\\"\",no-port-forwarding,no-x11-forwarding,no-agent-forwarding
  <ssh_keys_2>\n\nTo configure the authorized accesses for the users, you have to
  set up a valid\n`pi-hoole` configuration file. The latter uses the YAML syntax,
  and is located\nat `${XDG_CONFIG_DIRECTORY}/pi-hoole/config.yaml`.  It has two root
  fields:\n`groups` and `repositories`.\n\nYou can define groups of users, and grant
  certain rights to a group, effectively\ngranting there rights to each users who
  are member of the group.\n\nGroup names are prefixed by `+`, and user names are
  prefixed by `.`.\n\nThen, if you want to create one group `ogma` which contains
  the users `lgeorget`\nand `lthms`:\n\n    groups:\n      +ogma: [.lthms, .lgeorget]\n\nYou
  can create as many groups as you want, and one user may be added to several\ngroups.
  Currently, nested groups are not allowed (*i.e.* a group being member of\nanother
  group).\n\nThe `repositories` field allows for defining which repositories are available,
  and\nwhat given users can do with these repositories. The contents of the\n`repositories`
  is a map, where keys are `path` to the repositories (relative to\n`HOME` directory),
  and values are maps from role to rights.\n\nFor instance, given the following configuration:\n\n
  \   repositories:\n      my/first/repo:\n        .lthms: +w\n        +contrib: +r
  +w[master]\n        anon: +r\n\n      my/second/repo:\n        .lthms: +r\n        .lgeorget:
  +w\n\nWe declare two repositories, one located at `${HOME}/my/first/repo`, and another\nat
  `${HOME}/my/second/repo`. The user `lthms` (identified with `.lthms`) can\nread
  and write to this repository, to arbitrary branches. The members of the\ngroup `contrib`
  can read to any branch, but can only write to the `master`\nbranch. Finally, the
  anonymous user (through HTTP), can read to any branch.\n\nRead means being able
  to clone or pull. Write means being able to push.\n\nFor the second repository,
  `lthms` can read to any branch, when `lgeorget` can\nread and write to any branch.
  Therefore, it is not possible to clone\n`my/second/repo` through HTTP, because `anon`
  has not been granted any\nparticular rights.\n\n### Setting Up HTTP Proxy\n\n`pi-hoole-web`
  is a very simple HTTP proxy. It receives HTTP request, ideally\nissued by a `pijul`
  client, and turns them into `pijul` commands if the `anon`\nrole has been granted
  the required rights.\n\nCurrently, `pi-hoole-web` cannot be configured, and listen
  the port 8080. Also,\nit does not daemonify itself. The easiest way to set up a
  `pi-hoole-web`\ninstance in a reliable way is to use systemd, for instance with
  the following\nunit:\n\n```\n[Unit]\nDescription=HTTP Proxy for Pijul anonymous
  accesses\n\n[Service]\nType=simple\nUser=pijul\nGroup=pijul\nExecStart=/usr/bin/pi-hoole-web\nRestart=of-failure\nTimeoutStopSec=300\n\n[Install]\nWantedBy=multi-user.target\n```\n\nFor
  reference, the instance of `pi-hoole-web` responsible for `pijul.lthms.xyz`\nis
  behind a nginx server. One very straightforward nginx configuration can be:\n\n```\nserver
  {\n  listen 80;\n  server_name pijul.lthms.xyz;\n\n  access_log /var/log/nginx/pijul.lthms.xyz.access.log;\n
  \ error_log /var/log/nginx/pijul.lthms.xyz.error.log;\n\n  location / {\n    proxy_pass
  http://localhost:8080/;\n  }\n}\n```\n\n## Limitations\n\n### Private Branches\n\nThe
  command `pijul patch` does not have an argument to specify the branch from\nwhich
  a patch is initially fetched; as a consequence, having read access to a\nrepo, even
  for another branch where the patch is not applied, is enough.  For\nthis reason,
  if a user who obtains a hash for a patch of a branch they cannot\naccess can fetch
  the patch. That is, a patch is as private as its hash. Private\nbranches will eventually
  be supported in a better manner, but for now, private\nbranches should mean separated
  repositories.\n"
license-name: AGPL-3<commit_msg>Update from Hackage at 2018-05-05T18:21:31Z<commit_after>homepage: ''
changelog-type: markdown
hash: f014e8e20cdd2a85bb6c8ac48eea26780b11563a90155bf2e3bfb781cb169d50
test-bench-deps:
  base: ! '>=4.7 && <5'
  pi-hoole: -any
maintainer: lthms <<EMAIL>>
synopsis: Lightweight access control solution for the pijul vcs
changelog: ! "# Changelog for pi-hoole\n\n## pijul-0.2.0.0\n\n* `pi-hoole-shell`:
  When users connect to the host using SSH, but without any\n  command, they will
  get a summary of their rights\n* `pi-hoole-web`: Add a web page to list clonable
  pijul repositories with HTTP\n"
basic-deps:
  shakespeare: ! '>=2.0 && <2.1'
  warp: ! '>=3.0 && <3.3'
  regex-pcre: ! '>=0.91 && <0.95'
  bytestring: ! '>=0.10 && <0.11'
  wai: ! '>=3.0 && <3.3'
  optparse-generic: ! '>=1.0 && <1.4'
  unix: ! '>=2.0 && <2.8'
  base: ! '>=4.7 && <5'
  text: ! '>=1.0 && <1.3'
  megaparsec: ! '>=5.0 && <6.6'
  filepath: ==1.4.*
  process: ! '>=1.0 && <1.7'
  containers: ! '>=0.5.9 && <0.6'
  base58-bytestring: ! '>=0.1 && <0.2'
  pi-hoole: -any
  blaze-html: ! '>=0.9 && <0.10'
  http-types: ! '>=0.9 && <0.13'
  aeson: ! '>=1.0 && <1.4'
  yaml: ==0.8.*
  directory: ! '>=1.2.3 && <1.4'
all-versions:
- '0.1.0.0'
- '0.2.0.0'
author: <NAME>
latest: '0.2.0.0'
description-type: markdown
description: ! "# pi-hoole\n\n`pi-hoole` is a collection of tools to enforce access
  control for self-hosted\npijul repositories. It can be seen as a cgit-like solution,
  for authenticated\n(public key, SSH) and anonymous accesses. You can grant read
  and write accesses\nto a whole repository, or to a determined subset of branches.\n\n`pi-hoole`
  is distributed under the terms of the AGPL v3.\n\n## Getting Started\n\n### Building
  From Source\n\nIt should not be a surprise that `pi-hoole` is versioned under `pijul`,
  with the\npatch format introduced by `pijul-0.9`. Fair warning, use `pijul-0.10.1`
  and you\nshould be able to clone the `pi-hoole` repository.\n\n```bash\npijul clone
  https://pijul.lthms.xyz/pijul/pi-hoole\n```\n\nUnder the hood, `pi-hoole` is implemented
  in Haskell. We will need `stack` to\nbuild it.\n\n```bash\ncd pi-hoole\nstack build\n```\n\nWe
  are using the latest lts available, but `pi-hoole` has already been built\nwith
  `lts-10` (but does not build with older ones).\n\nThis build three executables:\n\n*
  `pi-hoole-cfg` generates a `.authorized_keys` file to enforce access control\n  for
  SSH.\n* `pi-hoole-shell` is called to determine if a authenticated user is allowed
  to\n  perform a given `pijul` command.\n* `pi-hoole-web` is a HTTP proxy to enforce
  access control for anonymous\n  requests.\n\n### Installing\n\nIn order to use `pi-hoole`
  on your server, the first step is to create a new,\ndedicated user (*e.g.* `pijul`).
  You then need to make `pijul` and\n`pi-hoole-shell` available to this user. Currently,
  we do not provide any\npackaging solution to that end, but this might change in
  the future. Although it\nis not mandatory, we consider both `pi-hoole-cfg` and `pi-hoole-web`
  have also\nbeen made available for the `pijul` user.\n\n### Configuring\n\n`pi-hoole`
  executables assume the configuration files are stored at\n`${XDG_CONFIG_DIRECTORY}/pi-hoole`,
  that is `~/.config/pi-hoole` by default.\n\nIn this directory, `pi-hoole` will scan
  the `keys/` directory, if it exists,\nto know the list of authorized authenticated
  users. One user may have as many\npublic key as required. Keys should be saved in
  file with the following filename\nscheme: `<user>(\\.<label>)?\\.pub`. Thus, `lthms.pub`,
  `lthms.laptop.pub` and\n`lthms.work.pub` are three valid public key filenames for
  the `lthms` user.\n\nTo generate a `.ssh/authorized_keys`, use `pi-hoole-cfg`.\n\n```bash\npi-hoole-cfg
  generate > ~/.ssh/authorized_keys\n```\n\nResulting file will be of the forms:\n\n
  \   command=\"pi-hoole-shell \\\".lthms\\\" \\\"${SSH_ORIGINAL_COMMAND}\\\"\",no-port-forwarding,no-x11-forwarding,no-agent-forwarding
  <ssh_keys_1>\n    command=\"pi-hoole-shell \\\".lthms\\\" \\\"${SSH_ORIGINAL_COMMAND}\\\"\",no-port-forwarding,no-x11-forwarding,no-agent-forwarding
  <ssh_keys_2>\n\nTo configure the authorized accesses for the users, you have to
  set up a valid\n`pi-hoole` configuration file. The latter uses the YAML syntax,
  and is located\nat `${XDG_CONFIG_DIRECTORY}/pi-hoole/config.yaml`.  It has two root
  fields:\n`groups` and `repositories`.\n\nYou can define groups of users, and grant
  certain rights to a group, effectively\ngranting there rights to each users who
  are member of the group.\n\nGroup names are prefixed by `+`, and user names are
  prefixed by `.`.\n\nThen, if you want to create one group `ogma` which contains
  the users `lgeorget`\nand `lthms`:\n\n    groups:\n      +ogma: [.lthms, .lgeorget]\n\nYou
  can create as many groups as you want, and one user may be added to several\ngroups.
  Currently, nested groups are not allowed (*i.e.* a group being member of\nanother
  group).\n\nThe `repositories` field allows for defining which repositories are available,
  and\nwhat given users can do with these repositories. The contents of the\n`repositories`
  is a map, where keys are `path` to the repositories (relative to\n`HOME` directory),
  and values are maps from role to rights.\n\nFor instance, given the following configuration:\n\n
  \   repositories:\n      my/first/repo:\n        .lthms: +w\n        +contrib: +r
  +w[master]\n        anon: +r\n\n      my/second/repo:\n        .lthms: +r\n        .lgeorget:
  +w\n\nWe declare two repositories, one located at `${HOME}/my/first/repo`, and another\nat
  `${HOME}/my/second/repo`. The user `lthms` (identified with `.lthms`) can\nread
  and write to this repository, to arbitrary branches. The members of the\ngroup `contrib`
  can read to any branch, but can only write to the `master`\nbranch. Finally, the
  anonymous user (through HTTP), can read to any branch.\n\nRead means being able
  to clone or pull. Write means being able to push.\n\nFor the second repository,
  `lthms` can read to any branch, when `lgeorget` can\nread and write to any branch.
  Therefore, it is not possible to clone\n`my/second/repo` through HTTP, because `anon`
  has not been granted any\nparticular rights.\n\n### Setting Up HTTP Proxy\n\n`pi-hoole-web`
  is a very simple HTTP proxy. It receives HTTP request, ideally\nissued by a `pijul`
  client, and turns them into `pijul` commands if the `anon`\nrole has been granted
  the required rights.\n\nCurrently, `pi-hoole-web` cannot be configured, and listen
  the port 8080. Also,\nit does not daemonify itself. The easiest way to set up a
  `pi-hoole-web`\ninstance in a reliable way is to use systemd, for instance with
  the following\nunit:\n\n```\n[Unit]\nDescription=HTTP Proxy for Pijul anonymous
  accesses\n\n[Service]\nType=simple\nUser=pijul\nGroup=pijul\nExecStart=/usr/bin/pi-hoole-web\nRestart=of-failure\nTimeoutStopSec=300\n\n[Install]\nWantedBy=multi-user.target\n```\n\nFor
  reference, the instance of `pi-hoole-web` responsible for `pijul.lthms.xyz`\nis
  behind a nginx server. One very straightforward nginx configuration can be:\n\n```\nserver
  {\n  listen 80;\n  server_name pijul.lthms.xyz;\n\n  access_log /var/log/nginx/pijul.lthms.xyz.access.log;\n
  \ error_log /var/log/nginx/pijul.lthms.xyz.error.log;\n\n  location / {\n    proxy_pass
  http://localhost:8080/;\n  }\n}\n```\n\nFor `pi-hoole-web` to work correcty, it
  needs an additional configuration file,\nassumed to be at `${XDG_CONFIG_DIRECTORY}/pi-hoole/web.yaml`.
  This file is\ncurrently very simple, it contains only three fields:\n\n* `title`:
  The title of the summary page\n* `baseUrl`: The base URL used to clone the repositories\n*
  `example`: Should be one of the public repositories\n\nHere is an example:\n\n```\ntitle:
  \"my repositories\"\nbaseUrl: \"https://my.repo.com\"\nexample: \"pi-hoole\"\n```\n\nIf
  you add a file called `description` in the `.pijul` directory of your public\nrepositories,
  its content will be used by `pi-hoole-web` when it gives a summary\nof the public
  repositories.\n\n## Limitations\n\n### Private Branches\n\nThe command `pijul patch`
  does not have an argument to specify the branch from\nwhich a patch is initially
  fetched; as a consequence, having read access to a\nrepo, even for another branch
  where the patch is not applied, is enough.  For\nthis reason, if a user who obtains
  a hash for a patch of a branch they cannot\naccess can fetch the patch. That is,
  a patch is as private as its hash. Private\nbranches will eventually be supported
  in a better manner, but for now, private\nbranches should mean separated repositories.\n"
license-name: AGPL-3
{'fraction_non_alphanumeric': 0.13447015834348355, 'fraction_numerical': 0.01991473812423873, 'mean_word_length': 3.6321579689703807, 'pattern_counts': {'":': 0, '<': 51, '<?xml version=': 0, '>': 53, 'https://': 3, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 6, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7525566', 'n_tokens_mistral': 6057, 'n_tokens_neox': 5816, 'n_words': 1897}