semvec/pypi-packages huggingface dataset:
trac-GenshiMacro 0.1
Write Genshi templates in Trac wiki pages
License: BSD
Keywords: trac plugin

Genshi processor for wiki pages
===============================

Description
-----------

The GenshiMacro allows you to write and render Genshi templates directly
in wiki pages with a new ``Genshi`` processor.

Your templates will have access to the request as ``req``, which can be
useful for tasks like URL generation, rendering form tokens for POST
requests, and checking for a logged-in user.

Note: no security considerations whatsoever went into the making of
this plugin.  It might be a terrible idea.  Trac core dev Remy Blank
said::

  > Genshi templates allow executing arbitrary Python code. So you basically
  > give users who can insert the macro anywhere (wiki page, ticket comment,
  > etc) permission to act as the user running Trac, including running run
  > any shell command.
  >
  {{{#!Genshi
  <div>${open('/etc/apache2/htpasswd').read()}</div>
  }}}
  
  {{{#!Genshi
  <?python
    import os
    os.system("rm /path/to/env/db/trac.db")
  ?>
  }}}
  >
  > So my advice is, only enable this macro on sites where you trust *all*
  > users who can edit *any* wiki text with the web server's account.

Configuration and Usage
-----------------------

To use the plugin, install it in your Trac environment and enable its 
components in ``trac.ini``::

  [components]
  genshimacro.* = enabled

You can then write Genshi templates directly in wiki pages like so::

  {{{
  #!Genshi
  <div xmlns:py="http://genshi.edgewall.org/">
   <py:choose>
    <py:when test="req.session.authenticated">
     <form method="POST" action="${req.href.newticket()}">
      <input type="text" name="field_summary" placeholder="My new ticket"
             id="field-summary" />
      <input type="hidden" name="__FORM_TOKEN" value="${req.form_token}" />
      <input type="submit" />
     </form>
    </py:when>
    <py:otherwise>
     <b>To file a new ticket, you'll need to
        <a href="${req.href.login()}">log in</a> or
        <a href="${req.href.register()}">create an account</a>
        first.</b>
    </py:otherwise>
   </py:choose>
  </div>  
  }}}
ssmrandom 0.3
Entropy distribution using SSM (source-specific multicast)
License: BSD

Introduction
------------

This is an experiment with using source specific multicast to distribute 
high-quality entropy to consumers. The package contains a single script which 
can act as both a sender and receiver.

Installation
------------

# pip install ssmrandom

In order for this to work your network and hosts must be able to support 
SSM which in turn requires IGMP v3. For modern Linux and Windows this is
enabled by default. For some network equipment (eg juniper) you must enable
IGMP v3 explicitly (v2 is the default).


Quick Start
-----------

On the entropy producer (using the default multicast group and port):

    # ssmrandom send -r /dev/urandom -t 32 -g 232.0.1.100 -p 49999 -L info 

On the entropy consumer(s):

    # ssmrandom recv -o /var/run/rnd-pipe -g 232.0.1.100 -p 49999 <ip-of-producer>

    # rngd --rng-device=/var/run/rnd-pipe --rng-driver=stream --fill-watermark=90% --feed-interval=1


The idiots entropy distribution protocol (IEDP):
------------------------------------------------

Messages are JSON objects with 3 keys:

- v (version): the protocol version - '1.0' for this version
- s (source): identifies the source of the random data, eg the name of a hw device
- d (data): base64-encoded random data

Example

    {'s': '/dev/qrandom0','v':'1.0','d': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'}

For security this can be signed, which is the reason for having framing at all.

Security issues
---------------

Collecting and adding external data to your entropy pool is a tricky issue. Adding
multicast to the mix makes it quite hard to analyze. This experiment is trying to 
investigate the properties of a system for distributing entropy in an efficient and
way. A couple of issues that are being investigated:

- how much entropy do you have to consume in order to pick a random sample
from the multicast feed?
- how expensive would it be to validate signatures on each json mesage?
- how good is rngtools at picking up bad entropy?


News
====

0.3
----

*Release date: Fri Aug 17 15:12:12 CEST 201*

* support for redundant transmitters
* debian packaging 
* + lots of minor fixes and cleanups

0.2
-----

*Release date: Thu Aug 16 11:02:35 CEST 2012*

* First public release
sentry-tracpost 0.3.0
A Sentry extension which integrates with Trac
License: BSD

sentry-tracpost
==============

An extension for Sentry which integrates with Trac. It will send Trac tickets over XML RPC.

This is still Alpha code and not Recommended for Production use.

:copyright: (c) 2012 by Josh Harwood.
:license: BSD, see LICENSE for more details.
django-session-csrf-cookie 0.1
Django middleware that works with session-csrf and sends a CSRF token cookie.
License: BSD

What is this?
-------------

``django-session-csrf-cookie`` is Django middleware that provides a
CSRF token cookie when using `django-session-csrf
<https://github.com/mozilla/django-session-csrf/>`_.  By design,
django-session-csrf does not require a CSRF token cookie, but such a
cookie is useful for AJAX requests and other web APIs, since it allows
the client to get the CSRF token without parsing HTML.  (Note that the
cookie is not used by the server for any purpose, so the security hole
django-session-csrf was designed to fix is still fixed.)  



Installation
------------

From PyPI::

    pip install django-session-csrf-cookie

From github::

    git clone git://github.com/trustcentric/django-session-csrf-cookie.git

Add ``session_csrf_cookie.CsrfCookieMiddleware`` to your ``MIDDLEWARE_CLASSES``
below ``session_csrf.CsrfMiddleware``::

    MIDDLEWARE_CLASSES = (
        ...
        'session_csrf.CsrfMiddleware',
        'session_csrf_cookie.CsrfCookieMiddleware',
        ...
    )

Add ``session_csrf_cookie`` to ``INSTALLED_APPS``.


Settings
--------

``session-csrf-cookie-middleware`` can be controlled using the
following settings:

    ``CSRF_COOKIE_NAME``
        The name used for the CSRF token cookie.

        Default: ``csrftoken``

    ``CSRF_COOKIE_DOMAIN``
        The domain to be used when setting the CSRF cookie.

        Default: None

    ``CSRF_COOKIE_SECURE``
        Whether to use a secure cookie for the CSRF cookie.

        Default: False

    ``CSRF_COOKIE_HTTPONLY``
        Whether to set the HTTPOnly flag on the CSRF cookie.

        Default: False