[sr #110072] Remove "history" project

[Ineiev]

Update of sr #110072 (project administration):

  Status:None => In Progress
 Assigned to:None => ineiev 

___

Follow-up Comment #1:

Please login and confirm with a non-anonymous comment. Originator Email can't
substitute authentication.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[sr #110072] Remove "history" project

[anonymous]

URL:
  

 Summary: Remove "history" project
 Project: Savannah Administration
Submitted by: None
Submitted on: Thu 24 Oct 2019 08:24:33 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: jo...@fsf.org
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The "history" project is empty and can be removed.

-john





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

Fyi: this list, savannah-hackers, just had it's subject [tag] and footer removed

[sysadmin]

The Free Software Foundation has changed the GNU Mailman settings on
this list. The short version is that any subject prefix or message
footer has been removed, allowing us to turn off DMARC from munging.
Any list administrator for this list is free to change these settings
back, instructions are below.

The change is to better deal with increased adoption of the DMARC email
standard. The default Mailman settings were causing messages sent from
users with strict DMARC policy domains like yahoo.com to be rejected
when sent to list subscribers by Mailman. See the end of this email for
a technical overview of DMARC and DKIM. There are two main ways to fix
the issue by changing Mailman list settings.

The first option, and the preferable way for discussion lists, is what
we call the "unmodified message fix." There are Mailman list settings
which modify the messages by adding a subject prefix (e.g. [list-name])
or a footer. Modifying the message breaks DKIM message signatures and
thus DMARC, so we just turn those off. Many lists are already this way
and there is no change for them. Instead of using the subject prefix to
identify a list, subscribers should use the List-Id, To, and Cc headers.
List footer information can also be be put in the welcome email to
subscribers and the list information page by list administrators.

We changed the default for new lists to send unmodified messages, and
are now updating existing discussion lists to the new default. We
emailed all list administrators and moderators and Savannah group admins
to allow them to opt in to the alternate fix before we made this
change. However, not all lists had a valid administrator contact.

The second option is for lists which want or need to continue to modify
the message, for example with subject prefix or footer settings. In this
case we turn on a Mailman list setting called dmarc_moderation_action:
"Munge From". With this, if a strict DMARC sender sends to the list, we
alter the headers of that message like so:

A message sent to the list:

From: Anne Example Person 

Is modified by Mailman and sent to subscribers as:

From: Anne Example Person via Alist 
Reply-To: Anne Example Person 

Without going into all of the details, here's a few points about why we
concluded the unmodified message fix is better for discussion
lists. Email clients don't all treat munged messages the same way as
unmunged, and humans read these headers so it can confuse people,
causing messages not to be sent to the expected recipients. GNU Mailman
has an option to do "Munge From" always, but does not recommend using
it[1]. While we're not bound by what others do, it's worth noting that
other very large free software communities like Debian GNU/Linux have
adopted the unmodified message fix[2]. The unmodified messages fix
avoids breaking DKIM cryptographic signatures, which show the message
was authorized by the signing domain and seems like a generally good
security practice. Tools to manage patches, for example patchew, use the
from field and are tripped up by from munging.

For any Mailman list administrator who wants to change or look over the
relevant settings: The dmarc_moderation_action setting is under "Privacy
Options" subsection "Sender Filters". The only options that should be
selected are "Accept" or "Munge From", along with corresponding changes
to the subject_prefix option under "General Options", and msg_footer is
under "Non-digest options".

If no list administrators or moderators are around for this list, anyone
should feel free to try to track them down or figure out who should
become one and explain in detail by replying to sysad...@gnu.org. Please
be patient, this process may take several weeks.

Please send any questions that should be public to mail...@gnu.org. For
private ones, just reply to sysad...@gnu.org.

For the general announcement of these changes, please read
https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html
and
https://lists.gnu.org/archive/html/savannah-hackers-public/2019-09/msg00016.html


A short DMARC technical overview:

DMARC policy is a DNS txt record at a _dmarc subdomain. For example:

$ host -t txt _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100;
rua=mailto:address@hidden;;;

The only important thing there for our purpose is p=reject. p=reject
means that conforming mail servers that receive mail with a from header
of *@yahoo.com will reject that email unless it was either 1. sent from
Yahoo's email servers, or 2. its DKIM signature is verified. A DKIM
signature[5] is a public key cryptographic signature of the email body
and some headers included in the message header "DKIM-Signature". A
verified DKIM signature means that email body and signed headers have
not been modified.

Comprehensive resources about DMARC tend to downplay or ignore its
problems, but some that have helped me are Wikipedia[6], the Mailman
wiki[1], dmarc.org wiki[7], and the DMARC rfc[8].

[savannah-help-public] [sr #110071] removing empty Savannah project

[Mark Wielaard]

URL:
  

 Summary: removing empty Savannah project
 Project: Savannah Administration
Submitted by: mark
Submitted on: Thu 24 Oct 2019 05:56:02 PM CEST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: m...@klomp.org
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

We have an empty Savannah project that was once setup for code that eventually
was integrated into the main GNU project (see project description):

Could you cleanup the project and associated (empty) repositories to clean up
Savannah a little?

https://savannah.gnu.org/projects/cp-tools/

https://web.cvs.savannah.gnu.org/viewvc/cp-tools/
https://git.savannah.gnu.org/git/web/cp-tools.git/
https://git.savannah.gnu.org/r/web/cp-tools.git/




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[savannah-help-public] [sr #110070] Compatibility between Savannah and REUSE

[Marco Bresciani]

Follow-up Comment #2, sr #110070 (project administration):

Well,
  this is FSF Europe that created these recommendations following some other
recommendations and standard (see https://reuse.software/comparison/), so my
concern is if FSFE is creating something that can be considered compatible
with Savannah requirements for projects, or not.

If not (and that's a problem!), well, I think it's up to GNU, FSF and FSFE to
discuss about the issue and change something. If the two are not compatible,
it's frankly ridiculous to continue the effort on REUSE (that came later than
Savannah and GNU...).

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[savannah-help-public] [sr #110070] Compatibility between Savannah and REUSE

[Ben Dukker]

Follow-up Comment #1, sr #110070 (project administration):

To my oppinion fsf and gnu should pull 
away there hands from spdx.
And go on with their own efforts.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[savannah-help-public] [sr #110070] Compatibility between Savannah and REUSE

[Marco Bresciani]

URL:
  

 Summary: Compatibility between Savannah and REUSE
 Project: Savannah Administration
Submitted by: marcobresciani
Submitted on: Thu 24 Oct 2019 01:46:36 PM CEST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hello,
  I'm thinking about aplpying the REUSE recommendations (by FSF Europe) to my
projects here on Savannah.

See https://reuse.software/ and https://reuse.software/faq/

Are the two things compatible?




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[savannah-help-public] removed project , not complete

[bendikker]

I wonder why only a projects webpage will be
removed when removing a project.

gplquiz
removed:
http://savannah.gnu.org/projects/gplquiz
not removed:
http://web.cvs.savannah.gnu.org/viewvc/gplquiz
http://git.savannah.gnu.org/git/web/gplquiz.git
http://git.savannah.gnu.org/r/web/gplquiz.git

licenseweb
removed:
http://savannah.gnu.org/projects/licenseweb
not removed:
http://web.cvs.savannah.gnu.org/viewvc/licenseweb
http://git.savannah.gnu.org/git/web/licenseweb.git
http://git.savannah.gnu.org/r/web/licenseweb.git

make-srpm
removed:
http://savannah.gnu.org/projects/make-srpm
not removed:
http://git.savannah.gnu.org/git/web/make-srpm.git
http://git.savannah.gnu.org/r/web/make-srpm.git

pdatacrypt
removed:
http://savannah.gnu.org/projects/pdatacrypt
not removed:
http://git.savannah.gnu.org/git/web/pdatacrypt.git
http://git.savannah.gnu.org/r/web/pdatacrypt.git


--

https://www.fsf.org/resources/webmail-systems/





--

[savannah-help-public] [sr #110065] Enable mirroring for poke.git in github

[Jose E. Marchesi]

Follow-up Comment #4, sr #110065 (project administration):

ping

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

Re: [savannah-help-public] Cannot access Savannah

[Ineiev]

Hello, Ron;

On Wed, Oct 23, 2019 at 02:48:11AM -0400, Ron Schnell wrote:
>
> I am getting authentication errors while trying to perform git operations
> on Savannah.  I reset my password from the website, and confirmed that my
> public key is correct, but git (and ssh) prompts me for a password and the
> newly reset password still does not work.

The website password is irrelevant, you should only use your ssh
key.

> My Savannah username is "ronnieschnell".

As far as I can see, your account isn't a member of any group;
perhaps you can use anonymous clones, can't you?


signature.asc
Description: PGP signature

[savannah-help-public] [sr #110069] Please delete http://savannah.gnu.org/projects/gplquiz

[Ineiev]

Update of sr #110069 (project administration):

  Status:None => Done   
 Assigned to:None => ineiev 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Removed.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/